Messages in this thread | | | Date | Fri, 26 Nov 1999 02:42:25 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [PATCH] Fix compilation warnings in dquot.c of 2.2.14pre8 |
| |
On Thu, 25 Nov 1999, Alexander Viro wrote:
>In principle it tells how hard do we want to trim icache... Question >about plans goes to Andrea, AFAICS.
I think we sure want to trim the icache and the dcache more aggressively: before we really gets so low on memory to generate swapins. Actually we can be suboptimal in some condition where having ram for the cache is far more important than caching lots of dentries and inodes. This is only a performance issue of course the callbacks in do_try_to_free_pages make the system perfectly stable just now.
The first idea that cames to my mind is to run some dcache/icache shrunk in do_try_to_free_pages() before shrink_mmap if the number of inodes is over a "soft limit" and there are unused (freeable) inodes/dentries.
>> So the question is: eliminate "count" and "goal" completely? > >Well, if you care about this printk - don't, otherwise count is bitbucket >fodder. As for the goal (in free_inode_memory) - depends on the future >plans. Andrea, your comments?
Actually there isn't free_inode_memory anymore. There's a prune_icache() for the icache like there is a prune_dcache() for the dcache (they basically works the same now). The goal still make sense for the dquot that wants the icache to drop only a few inodes from the cache. We try some time to free some dcache and then some inode to try to generate some dquot even if the kmem_cache_alloc allocation failed. Looks ok to me.
Really the best thing to do there would be to port from 2.2.14pre my smarter prune_dcache so that we can just ask to prune_dcache to release _exactly_ enough dentries to make sure that X inodes will become unused so that the following prune_inodes(X) will sure drop _exactly_ X inodes and so we won't waste dentries and we'll make sure to free X inodes. But this is a very minor issue for 2.3.x...
-----------------------------------------------------------------------
I am more focused about what happens if we fail also to generate dquots by releasing inodes:
printk("VFS: No free dquots, contact mvw@planets.elm.net\n"); sleep_on(&dquot_wait); goto repeat; ^^^^^^^^^^^
NOTE: I am not complaing the last prune_d/icache effort, but I am complaining what happens after we official declare that we failed the dquot allocation.
That basically is a deadlock condition as if all processes in the system needs dquots at the same time while we are OOM and there's no inode to shrunk.
Every time there is a kind of:
while (!GFP());
we can probably deadlock. Note that this is not specific to the dquot path but it also the swapout path seems deadlock prone in 2.[23].*. To swapout we must generate the async buffer heads but if we are OOM we can't generate them and we'll end sleeping forever in the create_buffers() (buffer_wait waitiqueue precisely)... getblk() itself seems deadlock prone too to me as it can't fail and can enter an infinite loop in refill_freelist().
Of course it never happened to me to deadlock there as we have the ATOMIC pool and some specific pool for async buffers that make almost impossible to trigger such deadlocks but I am not completly happy by such infinite loops... hmm... And with the increased pressure done by jorunaling pinned buffers things could become even worse I think. For critical missions applications such deadlock conditions should be removed IMHO. Maybe I could start by fixing getblk... Comments?
Andrea
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |