> > We are "deadlocked".
>
> Not necessarily. You are assuming that kswapd cannot make any progress
> while the swapout is blocked.
>
> This is exactly why we added the 2.2.2 kpiod thread. It is an
> independent thread which carries out the blocking pageout operations on
> behalf of kswapd. If that thread becomes totally blocked, kswapd simply
> stops giving it more work to do, and devotes itself to rescuing the
> situation by removing existing clean pages from memory.
And if there are no more clean pages left?
I can imagine situation when:
*) there's lot of swap available
*) there are no clean pages available
Then I can see a deadlock.
> Currently we only use the kpiod thread for filemapped pageouts, but
> there is absolutely nothing to stop us from doing the same sort of thing
> for swapout. It is not hard, and it _does_ prevent the deadlock you
> describe. Remember, the networking is already resistent to momentary
> loss of GFP_ATOMIC memory, so as long as kswapd can keep making
> progress, nbd won't completely stall.
_if_ there are some clean pages left. I do not see what guarantees us
there's at least one clean page.
Pavel
-- I'm really pavel@ucw.cz. Look at http://195.113.31.123/~pavel. Pavel Hi! I'm a .signature virus! Copy me into your ~/.signature, please!- 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/