Messages in this thread |  | | Date | Mon, 25 Sep 2000 20:54:57 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks |
| |
Hi,
On Mon, Sep 25, 2000 at 09:32:42PM +0200, Andrea Arcangeli wrote:
> Having shrink_mmap that browse the mapped page cache is useless > as having shrink_mmap browsing kernel memory and anonymous pages > as it does in 2.2.x as far I can tell. It's an algorithm > complexity problem and it will waste lots of CPU.
It's a compromise between CPU cost and Getting It Right. Ignoring the mmap is not a good solution either.
> Now think this simple real life example. A 2G RAM machine running an executable > image of 1.5G, 300M in shm and 200M in cache.
OK, and here's another simple real life example. A 2GB RAM machine running something like Oracle with a hundred client processes all shm-mapping the same shared memory segment.
Oh, and you're also doing lots of file IO. How on earth do you decide what to swap and what to page out in this sort of scenario, where basically the whole of memory is data cache, some of which is mapped and some of which is not?
If you don't separate out the propagation of referenced bits from the actual page aging, then every time you pass over the whole VM working set, you're likely to find a handful of live references to some of the shared memory, and a hundred or so references that haven't done anything since last time. Anything that only ages per-pte, not per-page, is simply going to die horribly under such load, and any imbalance between pure filesystem cache and VM pressure will be magnified to the point where one dominates.
Hence my observation that it's really easy to find special cases where certain optimisations make a ton of sense, but you often lose balance in the process.
Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |