On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > > modularizing XFS and using an initrd be OK?)
> > >
> > > Yes, loading xfs from initrd should help. [At least it did during
> > > suse9.3 testing.]
> >
> > Once I modularized xfs and switched to using an initrd, the problem
> > disappeared.
>
> I reproduced it locally. Problem is that xfsbufd goes refrigerated,
> but someone still tries to wake it up *very* often. Probably something
> else in xfs needs refrigerating, too, but I'm not a XFS wizard...
Thanks Pavel - I've been reading the thread from the other side
of the fence, not understanding the swsusp side of things. :)
There are two ways the xfsbufd thread will wake up - either by its
timer going off (for it to flush delayed write metadata buffers)
or by being explicitly woken up when we're low on memory (in which
case it also flushes out dirty metadata, such that pages can be
cleaned and made available to the system).
Since the refrigerator() call is in place in the main xfsbufd loop,
I suspect we're hitting that second case here, where a low memory
situation is resulting in someone attempting to wakeup xfsbufd --
I'm not sure if this is the right way to check if we're in that
state, but does this patch help? (it would certainly prevent the
spurious wakeups, but only if the caller has PF_FREEZE set - will
that be the case here?)
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 08:59:38.973557728 +1000
@@ -1753,6 +1753,8 @@ pagebuf_daemon_wakeup(
int priority,
unsigned int mask)
{
+ if (current->flags & PF_FREEZE)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
