Re: [Regression/XFS/PM] Freeze tasks failed in xfsaild

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 13, 2017 at 06:31:39PM +0800, Yu Chen wrote:
> The xfs-buf/dm-1 should be freezed according to
> commit 8018ec083c72 ("xfs: mark all internal workqueues
> as freezable"), thus a easier way might be have to revert
> commit 18f1df4e00ce ("xfs: Make xfsaild freezeable
> again") for now, after this reverting the xfsaild/dm-1
> becomes non-freezable again, thus pm does not see this
> thread - unless we find a graceful way to treat xfsaild/dm-1
> as 'frozen' if it is waiting for an already 'frozen' task,
> or if the filesystem freeze is added in.
> 
> Any comments would be much appreciated.

Reverting 18f1df4e00ce ("xfs: Make xfsaild freezeable again")
would break the proper form of the kthread for it to be freezable.
This "form" is not defined formally, and sadly its just a form
learned throughout years over different kthreads in the kernel.

I'm also not convinced all our hibernation / suspend woes would be fixed by
reverting this commit, its why I worked instead on formalizing a proper freeze
/ thaw, which a lot of filesystems already implement prior to system
hibernation / suspend / resume [0].

I'll be respinning this series without the last patch, provided I'm able to
ensure I don't need the ext[234] hack I did in that thread. Can you test the
first 3 patches *only* on that series and seeing if that helps on your XFS
front as well?

[0] https://lkml.kernel.org/r/20171003185313.1017-1-mcgrof@xxxxxxxxxx

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux