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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
