[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5271193.sYRdkO0AkU@vostro.rjw.lan>
Date: Fri, 10 Jul 2015 01:22:55 +0200
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Oliver Neukum <oneukum@...e.com>
Cc: Dave Chinner <david@...morbit.com>,
Henrique de Moraes Holschuh <hmh@....eng.br>,
Len Brown <len.brown@...el.com>, Len Brown <lenb@...nel.org>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Alan Stern <stern@...land.harvard.edu>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux PM list <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 1/1] suspend: delete sys_sync()
On Thursday, July 09, 2015 09:32:51 AM Oliver Neukum wrote:
> On Thu, 2015-07-09 at 00:03 +0200, Rafael J. Wysocki wrote:
>
> > Nothing and I'm not discussing that (I've said that already at least once in
> > this thread).
> >
> > What I'm questioning is the "why" of calling sys_sync() from the kernel.
>
> That's strictly speaking two questions
>
> 1. Why do it in the kernel
>
> That is easy. It closes the window of a race condition.
>
> 2. Why do it at all
>
> In essence because the system becomes inactive. For example we say that
> data hits the disk after 30s maximum. We cannot meet such a limit unless
> we sync.
Absolute deadlines are not guaranteed to be met at all in general when
system suspend is used, at least from the user space perspective, so the
above is quite a bit of an overstretch.
> There are additional issues, such as a system appearing inactive during
> suspension and frankly the far greater likelihood of a crash.
I prefer the Alan's point, to be honest: it's a tradeoff between some extra
safety and some extra suspend overhead. Unfortunately, though, we don't have
any numbers allowing us to estimate how much extra safety it provides and so
to justify it quantitatively, so to speak.
Thanks,
Rafael
--
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