Re: VM deadlock

[Chris Mason <mason@suse.com>]

On Wednesday, June 27, 2001 05:36:45 PM -0300 Rik van Riel
<riel@conectiva.com.br> wrote:

> On Wed, 27 Jun 2001, Chris Mason wrote:
>> On Wednesday, June 27, 2001 04:43:28 PM -0300 Rik van Riel
> 
>> > If you don't have free memory, you are limited to 2 choices:
>> > 
>> > 1) wait on IO
>> > 2) spin endlessly, wasting CPU until the IO is done
>> 
>> Ok, I need to describe the problem a little better.  reiserfs
>> inodes need to be logged, which means you have to join/start a
>> transaction in order to write them.
> 
>> So, the only time reiserfs_write_inode needs to do something is for fsync
>> and/or O_SYNC writes, and all it needs to do is commit the transaction.
>> 
>> Any time kswapd is calling write_inode, it is just trying to
>> free the inode struct, and reiserfs can safely ignore the write
>> request, regardless of if a sync is requested.
> 
> OK, sounds sane enough to me ;)

Well, I guess that's one word for it...I'll bet $5 Al's got a few others
;-) A better fix is to have private inode dirty lists....

> 
> So the fix is just to let reiserfs_write_inode always be
> asynchronous, independent of its arguments, as long as
> we're not in fsync() or O_SYNC.

I think so, but there needs to be some testing there.  Note that I managed
to run a heavy stress test (put my machine far, far into swap) for 3 solid
days without hitting this.  When I initially made the dirty_inode kludge, I
could trigger it in ~10 minutes.  

> 
> OTOH, if we are called synchronously, we could also just
> walk down the code path taken when we _are_ called by
> fsync(), right ?

sorry, not sure what you mean.  In fsync we do a commit, which might wait
on the current transaction, so kswapd can't go down that code path.

-chris