[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150508205233.72b9fae3@lxorguk.ukuu.org.uk>
Date: Fri, 8 May 2015 20:52:33 +0100
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Len Brown <lenb@...nel.org>
Cc: Alan Stern <stern@...land.harvard.edu>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM list <linux-pm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Len Brown <len.brown@...el.com>
Subject: Re: [PATCH 1/1] suspend: delete sys_sync()
> > Some of this however is crappy suspend/resume handling. If the suspend
> > subsystem was doing its job then for the cases of timeout triggered
> > suspend it would have triggered most of the disk writes ten seconds
> > before it tried to suspend properly ;-)
>
> No problem, continue to use s2ram on your system -- and to the extent
> that sync works, your data will be on disk. (sync reliability is a
> different topic...)
Ok let me ask the other obvious question. For all the mainstream
distributions do their default tools and setup sync such that removing it
from the kernel won't actually be noticable by users ?
If the answer is yes, then I shall shut up and stop worrying 8)
> Understand, however, there are systems which suspend/resume reliably
> many times per second, making policy choice of having the kernel hard-code
> a sys_sync() into the suspend path a bad idea.
I'm aware of that - I have a very nice ASUS T100TA.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists