Messages in this thread | | | Date | Thu, 19 Oct 2006 00:56:18 +1000 | From | Nick Piggin <> | Subject | Re: [RFC] Remove temp_priority |
| |
Martin J. Bligh wrote: >> Coming from another angle, I am thinking about doing away with direct >> reclaim completely. That means we don't need any GFP_IO or GFP_FS, and >> solves the problem of large numbers of processes stuck in reclaim and >> skewing aging and depleting the memory reserve. > > > Last time I proposed that, the objection was how to throttle the heavy > dirtiers so they don't fill up RAM with dirty pages?
Now that we have the dirty mmap accounting, page dirtiers should be throttled pretty well via page writeback throttling.
> Also, how do you do atomic allocations? Create a huge memory pool and > pray really hard?
Well, yes. Atomic allocations as of *today* cannot do any reclaim, and thus they rely on kswapd to free their memory, and we keep a (not huge) memory pool for them. They also have to be able to handle failures, and by and large they do OK.
>> But that's tricky because we don't have enough kswapds to get maximum >> reclaim throughput on many configurations (only single core opterons >> and UP systems, really). > > > It's not a question of enough kswapds. It's that we can dirty pages > faster than they can possibly be written to disk. > > dd if=/dev/zero of=/tmp/foo
You can't catch that at the allocation side anyway because clean pagecache may already exist for /tmp/foo.
We've always done pretty well (in 2.6) with correctly throttling and limiting write(2) writes into pagecache, haven't we?
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |