Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]

[Pavel Machek <pavel@suse.cz>]

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?)

I should take some sleep now, so I can't test the patch, but I don't
think it will help. If someone has PF_FREEZE set, he should be in
refrigerator.

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
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/