On Wednesday, July 15, 2015 02:58:22 PM Brown, Len wrote: > > > -----Original Message----- > > From: Austin S Hemmelgarn [mailto:[email protected]] > > Sent: Wednesday, July 15, 2015 10:07 AM > > To: Pavel Machek; Len Brown > > Cc: [email protected]; [email protected]; linux- > > [email protected]; Brown, Len > > Subject: Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional > > > > On 2015-07-15 02:43, Pavel Machek wrote: > > > On Tue 2015-07-14 22:24:51, Len Brown wrote: > > >> From: Len Brown <[email protected]> > > >> > > >> The Linux kernel suspend path has traditionally invoked sys_sync(). > > >> > > >> But sys_sync() can be expensive, and some systems do not want > > >> to pay the cost of sys_sync() on every suspend. > > > > > > Have you measured how expensive it can be, and why it is expensive? > > > How expensive it is can vary widely, but it pretty much boils down to > > how much dirty data still needs written out, and how slow the storage it > > needs written to is. There's not really much that can be done in the > > kernel to change this, and most userspace suspend systems call sync > > themselves during the suspend sequence. > > Right. > And now, user-space gets is no longer forced to incur that > delay on every suspend if they do not want it. > > Yes, have measured this under many conditions. > The bottom line is that sys_sync() is rarely as fast as 1ms, > and is sometimes as slow as hundreds of ms. > > >> Why do you need CONFIG parameter? > > So that an OS that doesn't want to change their user-space, > can build a kernel that does what they want by default. > > Originally I had the config parameter remove this code entirely, > which would achieve the same goal. > But Rafael prefers the sysfs attribute always exist > and the config simply set the default.
Indeed. And so I'm queuing this patch up for 4.3 (with a couple of minor fixups). Thanks, Rafael -- 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/
