Andrew Morton wrote:
On Sat, 27 Jan 2007 17:19:21 -0500
Rik van Riel <[email protected]> wrote:
Andrew Morton wrote:
Of course it would. But how do you know it is "too expensive"? We "scan
all the vmas mapping a page" as a matter of course in the page scanner -
millions of times a minute. If that's "too expensive" then ouch.
We can do it lazily.
At mlock time, move pages onto the mlocked list, unless they
are there already.
Needs another page flag to determine what list the page is on (eek).
On munlock, move pages to the active list.
We'd need to determine whether some other vma has mlocked the page too.
That's either the page_struct refcount or the vma walk. The latter is
equivalent to what I'm suggesting.
It doesn't have to be 100% accurate. The pages that are mapped
both mlocked and non-mlocked will probably be only shared
libraries.
For mlock-only
memory (shared memory segments?) we could add a simple check
to see if the next process on the list has the page mlocked,
checking only that one.
As long as we get it right for the large objects, it should be
fine.
I'm still not sure what problem we're trying to solve here.
Knowing how many mlocked pages there are in a zone doesn't sound terribly
interesting and I don't recall ever wanting to know that.
Being able to keep mlocked pages off the LRU altogether sounds more useful.
It's all rather a tight corner case - people don't use mlock much.
Just because it's not common does not mean you can just ignore
it and hope Linux doesn't unexpectedly fall over.
One thing that knowing the amount of mlocked data in each zone
(and node) would allow us to do is spread the mlocked memory
around a little better at allocation time. This could prevent
some of the "I started a 6GB Oracle on my 8GB system and it
immediately fell over" bugs.
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
