Messages in this thread | | | Date | Wed, 27 Jun 2001 16:52:25 -0400 | From | Chris Mason <> | Subject | Re: VM deadlock |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |