lkml.org 
[lkml]   [1999]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.039 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site