mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Dave Chinner <david@fromorbit.com>, Len Brown <lenb@kernel.org>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Len Brown <len.brown@intel.com>
Subject: Re: [PATCH 1/1] suspend: delete sys_sync()
Date: Tue, 07 Jul 2015 14:22:07 +0200	[thread overview]
Message-ID: <1632426.Ho6HuulePs@vostro.rjw.lan> (raw)
In-Reply-To: <20150707102507.GA13811@amd>

On Tuesday, July 07, 2015 12:25:07 PM Pavel Machek wrote:
> On Mon 2015-07-06 15:59:15, Rafael J. Wysocki wrote:
> > On Monday, July 06, 2015 01:06:45 PM Pavel Machek wrote:
> > > On Mon 2015-07-06 01:28:20, Rafael J. Wysocki wrote:
> > > > On Saturday, July 04, 2015 10:19:55 AM Alan Stern wrote:
> > > > > On Sat, 4 Jul 2015, Rafael J. Wysocki wrote:
> > > > > 
> > > > > > The only argument against dropping sys_sync() from the suspend code path
> > > > > > I've seen in this thread that I entirely agree with is that it may lead to
> > > > > > regressions, because we've done it practically forever and it may hide latent
> > > > > > bugs somewhere in block drivers etc.  Dropping it, though, is the only way
> > > > > > to see those bugs, if any, and if we want to ever fix them, we need to see
> > > > > > them.  That's why I think that it may be a good idea to allow people to
> > > > > > drop it if they are willing to accept some extra risk (via the kernel
> > > > > > command line, for example).
> > > > > 
> > > > > I'd be perfectly happy to have the sync selectable at runtime, one way 
> > > > > or another.  The three most reasonable options seem to be:
> > > > > 
> > > > > 	kernel command line
> > > > > 
> > > > > 	sysfs file
> > > > > 
> > > > > 	sysctl setting
> > > > > 
> > > > > The command line is less flexible (it can't be changed after booting).  
> > > > > Either of the other two would be fine with me.
> > > > 
> > > > We'll probably use a sysfs file (possibly plus a Kconfig option to set the
> > > > boot time default).
> > > 
> > > Android people can already do sync-less s2ram using existing
> > > interface. IMO they should just do it.
> > > 
> > > In any case, sysfs file + Kconfig is an overkill. We already have too
> > > many Kconfig options.
> > 
> > I don't think we can reach a general agreement on what's the *right* approach
> > with respect to the sys_sync() in the suspend code path, so the only way out
> > of this situation I can see is to make it configurable.
> 
> So first: not having general agreement does not mean we should
> introduce Kconfig + sysfs file. Second: your proposal of "lets sync if
> runtime was shorter than xxx" is over complex, but at least should not
> need Kconfig support...

The Kconfig part is only about setting the default at compile time, so I'm
not sure why you have any problems with it.


> Third: we have ioctl() based interface, and I guess android should use that
> one; it already has "s2ram without sync" method.

And that is tied to hibernation and therefore useless to people who don't
build that in.


> > > There's not a single Android phone supported by mainline
> > > kernel. I'm sure they have bigger problems than Android setting
> > > default sysfs values...
> > 
> > But perhaps we'd like to change that?
> 
> We'd like to, but lets start with the real hard stuff (merging support
> for Qualcomm chipsets) that is 1000000 LoC+, not with trivial tweaks
> that would be 1-line change, but we pollute code with Kconfig+sysfs
> making it 100..

It is suboptimal, but this is the only way I can see allowing us to make
any forward progress here.

Evidently, some people are not happy with the status quo and they also should
be able to cover their use cases with the mainline kernel, shouldn't they?

Rafael


  reply	other threads:[~2015-07-07 11:55 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-08  7:08 Len Brown
2015-05-08 14:34 ` Alan Stern
2015-05-08 16:36   ` Len Brown
2015-05-08 19:13     ` One Thousand Gnomes
2015-05-08 19:32       ` Len Brown
2015-05-08 19:52         ` One Thousand Gnomes
2015-05-08 20:39           ` Rafael J. Wysocki
2015-05-08 20:30         ` Rafael J. Wysocki
2015-05-09 19:59           ` Alan Stern
2015-05-09 20:25             ` Henrique de Moraes Holschuh
2015-05-11 20:34               ` Len Brown
2015-05-12  6:11                 ` Oliver Neukum
2015-06-25 17:11                 ` Henrique de Moraes Holschuh
2015-06-30 20:04                   ` Len Brown
2015-07-01 12:21                     ` Henrique de Moraes Holschuh
2015-07-02  3:07                       ` Len Brown
2015-07-03  1:42                         ` Dave Chinner
2015-07-04  1:03                           ` Rafael J. Wysocki
2015-07-04  8:50                             ` Geert Uytterhoeven
2015-07-05 23:25                               ` Rafael J. Wysocki
2015-07-04 14:19                             ` Alan Stern
2015-07-05 23:28                               ` Rafael J. Wysocki
2015-07-06 11:06                                 ` Pavel Machek
2015-07-06 13:59                                   ` Rafael J. Wysocki
2015-07-07 10:25                                     ` Pavel Machek
2015-07-07 12:22                                       ` Rafael J. Wysocki [this message]
2015-07-06  0:06                             ` Dave Chinner
2015-07-06 11:11                               ` Pavel Machek
2015-07-06 13:52                               ` Rafael J. Wysocki
2015-07-07  1:17                                 ` Dave Chinner
2015-07-07 12:14                                   ` Rafael J. Wysocki
2015-07-07 13:16                                     ` Oliver Neukum
2015-07-07 14:32                                       ` Rafael J. Wysocki
2015-07-07 14:38                                         ` Oliver Neukum
2015-07-07 15:03                                           ` Alan Stern
2015-07-07 22:20                                             ` Rafael J. Wysocki
2015-07-08 11:20                                               ` Pavel Machek
2015-07-08 14:40                                                 ` Alan Stern
2015-07-08 22:04                                                   ` Rafael J. Wysocki
2015-07-07 22:11                                           ` Rafael J. Wysocki
2015-07-08  7:51                                             ` Oliver Neukum
2015-07-08 22:03                                               ` Rafael J. Wysocki
2015-07-09  7:32                                                 ` Oliver Neukum
2015-07-09 23:22                                                   ` Rafael J. Wysocki
2015-08-04 19:54                                                     ` Pavel Machek
2015-07-08 11:17                                         ` Pavel Machek
2015-07-07 13:42                                   ` Takashi Iwai
2015-07-06 10:15                             ` Ming Lei
2015-07-06 10:03           ` Pavel Machek
2015-05-11  1:44 ` Dave Chinner
2015-05-11 20:22   ` Len Brown
2015-05-12 22:34     ` Dave Chinner
2015-05-13 23:22   ` NeilBrown
2015-05-14 23:54     ` Dave Chinner
2015-05-15  0:34       ` Rafael J. Wysocki
2015-05-15  0:40         ` Ming Lei
2015-05-15  0:59           ` Rafael J. Wysocki
2015-05-15  5:13             ` Ming Lei
2015-05-15 10:35             ` One Thousand Gnomes
2015-05-18  1:57               ` NeilBrown
     [not found]                 ` <CAJvTdKn_0EZ0ZuqO2e4+ExD8kFWcy78fse4zHr3uFZODOroXEg@mail.gmail.com>
2015-06-19  1:09                   ` Dave Chinner
2015-06-19  2:35                     ` Len Brown
2015-06-19  4:31                       ` Dave Chinner
2015-06-19  6:34                         ` Len Brown
2015-06-19 23:07                           ` Dave Chinner
2015-06-20  5:26                             ` Len Brown
2015-05-15  1:04       ` NeilBrown
2015-05-15 14:20         ` Alan Stern
2015-05-15 14:32           ` Alan Stern
2015-05-15 14:19       ` Alan Stern
2015-07-06 10:07   ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1632426.Ho6HuulePs@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=david@fromorbit.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=hmh@hmh.eng.br \
    --cc=len.brown@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®