[lkml]   [2001]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: VM deadlock

On Wednesday, June 27, 2001 05:36:45 PM -0300 Rik van Riel
<> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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