Re: [test patch] dirty shared mappings (was Re: ... fragmentation)

Linus Torvalds (torvalds@transmeta.com)
Wed, 7 Jan 1998 15:37:48 -0800 (PST)


On Wed, 7 Jan 1998, Benjamin C.R. LaHaise wrote:
>
> Well, which of the two approaches do we want to take? I already have
> a working (and by now, well tested) pte lists patch, with the drawback of
> doubling the size of page tables. Alternatively, throwing together a
> patch that walks i_mmap and undirties pages wouldn't be too hard. <pause>
> Done! This is untested, but it compiles and looks right. Just looking at
> how it works shows that it'll probably thrash the cache quite badly,
> whereas the pte_list stuff pays the price over time by linking/unlinking.

Right. This was more like what I had in mind if the problem ever turned
out to be a real issue - Ted seems to indicate that it might well be an
issue for some cases.

It's fairly expensive CPU-wise, but it's so _simple_ that it's obviously
correct. It doesn't help with the problem of specific physical pages, but
it helps with all the other issues, which is one more reason why I think
that the physical page allocator really is a totally different matter.

> Hmmm.... I finally agreeing with Linus - now if only shared private
> pages had an inode mapping we could walk... But then they must all be
> clean (unless they're a privately mapped file not in the swap cache and
> there's an exec). Ho hum.

No, they don't all have to be clean, it's just that we'd have to have some
way of allocating pages for the inode for backing store (so that we can do
a page-out() to the right location). Essentially, the page area moves from
being just a anonymous linear area of pages for swap into having some
structure, which is obviously painful. I think it's probably the right
thing to do, but I don't really have a good idea on _how_ to do it..

Linus