Re: Lockups with 2.4.14 and 2.4.16

From: Jan Kara (jack@suse.cz)
Date: Fri Dec 14 2001 - 14:21:08 EST


  Hello,

> Chris Mason wrote:
> > Ok, Johan sent along stack traces, and the deadlock works a little like this:
> >
> > linux-2.4.16 + reiserfs + quota v2
> >
> > kswapd ->
> > prune_icache->dispose_list->dquot_drop->commit_dquot->generic_file_write->
> > mark_inode_dirty->journal_begin-> wait for trans to end
>
> uh-huh.
...
> > The only fix I see is to make sure kswapd doesn't run shrink_icache, and to
> > have it done via a dedicated daemon instead. Does anyone have a better idea?
>
> Well, we already need to do something like that to prevent the
> abuse of keventd in there. It appears that somebody had a
> problem with deadlocks doing the inode writeout in kswapd but
> missed the quota problem.
>
> Is it possible for the quota code to just bale out if PF_MEMALLOC
> is set? To leave the dquot dirty?
  Nope. Writing of dquots works following way:
When dquot is used (referenced by inode) it's written only on explicit sync.
Otherwise it's just marked dirty. When last reference from inode to dquot is
dropped, dquot is written to disk (if marked dirty). Then it's put to the free
list from where it can be evicted by prune_dqcache().
  So when you don't write dquot when the last reference is dropped you
have to solve following issues:
  * you need to assure dquot is written sometimes
  * you need to make prune_dqcache() skip dirtified dquots

  The first problem probably can be solved using bdflush...
The second one is probably trivial as dquots use small amount of memory (~100 bytes
per user) and so we don't have to care much about vm balancing.

                                                                        Honza

--
Jan Kara <jack@suse.cz>
SuSE CR Labs
-
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/



This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:28 EST