On Sat 2015-08-01 01:56:19, Rafael J. Wysocki wrote:
> On Friday, July 31, 2015 12:02:36 PM Len Brown wrote:
> > On Wed, Jul 22, 2015 at 4:55 AM, Oliver Neukum wrote:
> > > On Wed, 2015-07-22 at 03:25 +0200, Rafael J. Wysocki wrote:
> > >> And it is more pain for me to change the user space on eac
On Friday, July 31, 2015 12:02:36 PM Len Brown wrote:
> On Wed, Jul 22, 2015 at 4:55 AM, Oliver Neukum wrote:
> > On Wed, 2015-07-22 at 03:25 +0200, Rafael J. Wysocki wrote:
> >> And it is more pain for me to change the user space on each of them to
> >> write to the new sysfs file on every boot t
On Wed, Jul 22, 2015 at 4:55 AM, Oliver Neukum wrote:
> On Wed, 2015-07-22 at 03:25 +0200, Rafael J. Wysocki wrote:
>> And it is more pain for me to change the user space on each of them to
>> write to the new sysfs file on every boot than to set a kernel Kconfig
>> option once.
>
> So why at all?
On Wed, 2015-07-22 at 03:25 +0200, Rafael J. Wysocki wrote:
> And it is more pain for me to change the user space on each of them to
> write to the new sysfs file on every boot than to set a kernel Kconfig
> option once.
So why at all? If you really need this in sysfs, why not write
something like
On Wed 2015-07-22 03:25:41, Rafael J. Wysocki wrote:
> On Tuesday, July 21, 2015 05:19:41 PM Pavel Machek wrote:
> > On Tue 2015-07-21 16:41:12, Rafael J. Wysocki wrote:
> > > Hi Pavel,
> > >
> > > On Tue, Jul 21, 2015 at 11:38 AM, Pavel Machek wrote:
> > > > On Sat 2015-07-18 01:54:09, Rafael J.
On Tuesday, July 21, 2015 05:19:41 PM Pavel Machek wrote:
> On Tue 2015-07-21 16:41:12, Rafael J. Wysocki wrote:
> > Hi Pavel,
> >
> > On Tue, Jul 21, 2015 at 11:38 AM, Pavel Machek wrote:
> > > On Sat 2015-07-18 01:54:09, Rafael J. Wysocki wrote:
> > >> On Wednesday, July 15, 2015 02:58:22 PM Br
Hi!
> >>And I'm not sure what you're talking about here. Who are the
> >>"affected users" in particular?
> >
> >Who does enter suspend to ram multiple times a second? Only android,
> >AFAICT. Can you run android on mainline kernel? No. Can you run
> >android on kernel with less that 100k lines of
On Tue 2015-07-21 20:01:15, Brown, Len wrote:
> > Who does enter suspend to ram multiple times a second? Only android
>
> One significant customer for fast suspend/resume
> is sufficient to justify Linux supporting fast suspend/resume.
So which customer is that? And does that customer really need
> Who does enter suspend to ram multiple times a second? Only android
One significant customer for fast suspend/resume
is sufficient to justify Linux supporting fast suspend/resume.
> Can you run android on mainline kernel? No
This is something we need to work together to help fix.
thanks,
-Len
On 2015-07-21 11:19, Pavel Machek wrote:
On Tue 2015-07-21 16:41:12, Rafael J. Wysocki wrote:
Hi Pavel,
On Tue, Jul 21, 2015 at 11:38 AM, Pavel Machek wrote:
On Sat 2015-07-18 01:54:09, Rafael J. Wysocki wrote:
On Wednesday, July 15, 2015 02:58:22 PM Brown, Len wrote:
[cut]
Why do you ne
On Tue 2015-07-21 16:41:12, Rafael J. Wysocki wrote:
> Hi Pavel,
>
> On Tue, Jul 21, 2015 at 11:38 AM, Pavel Machek wrote:
> > On Sat 2015-07-18 01:54:09, Rafael J. Wysocki wrote:
> >> On Wednesday, July 15, 2015 02:58:22 PM Brown, Len wrote:
>
> [cut]
>
> >> > >> Why do you need CONFIG paramet
Hi Pavel,
On Tue, Jul 21, 2015 at 11:38 AM, Pavel Machek wrote:
> On Sat 2015-07-18 01:54:09, Rafael J. Wysocki wrote:
>> On Wednesday, July 15, 2015 02:58:22 PM Brown, Len wrote:
[cut]
>> > >> Why do you need CONFIG parameter?
>> >
>> > So that an OS that doesn't want to change their user-spac
AM
> > > To: Pavel Machek; Len Brown
> > > Cc: r...@rjwysocki.net; linux...@vger.kernel.org; linux-
> > > ker...@vger.kernel.org; Brown, Len
> > > Subject: Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional
> > >
> > > On 2015-07-15 02:
.@vger.kernel.org; linux-
> > ker...@vger.kernel.org; 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:
> > >>
CH 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
> >>
> >> The Linux kernel suspend path has traditionally invoked sys_sync().
> >&g
On 2015-07-15 02:43, Pavel Machek wrote:
On Tue 2015-07-14 22:24:51, Len Brown wrote:
From: Len Brown
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 me
On Tue 2015-07-14 22:24:51, Len Brown wrote:
> From: Len Brown
>
> 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 expesive it can be, an
From: Len Brown
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.
So make sys_sync on suspend optional.
Create sysfs attribute /sys/power/pm_suspend_do_sync.
When set
On Sun, Jan 26, 2014 at 4:08 PM, Pavel Machek wrote:
> Dunno. Config option plus sysfs attribute is overdoing it a bit.
Agreed.
Have discussed w/ Rafael, and current plan is to simply delete.
Updated patch on the way...
thanks,
Len Brown, Intel Open Source Technology Center
--
To unsubscribe fr
Hi!
> From: Len Brown
>
> Linux suspend-to-RAM was unreliable when first developed,
> and so sys_sync() was invoked inside the kernel at the
> start of every suspend flow.
>
> Today, many devices are invoking suspend with
> high reliability and high frequency, and they don't
> want to be forced
> How about naming it as PM_SLEEP_FS_SYNC (and similarly in the sysfs
> files
> and variable names as well). Just to avoid confusion with
> "synchronous/async".
good point -- thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
On 01/23/2014 12:41 PM, Len Brown wrote:
> From: Len Brown
>
> Linux suspend-to-RAM was unreliable when first developed,
> and so sys_sync() was invoked inside the kernel at the
> start of every suspend flow.
>
> Today, many devices are invoking suspend with
> high reliability and high frequency
> > + depends on PM_SLEEP
>
> this is actually a suspend specific feature, and it should depends on
> SUSPEND instead?
yup, will update.
thanks,
-Len
On Thu, 2014-01-23 at 02:11 -0500, Len Brown wrote:
> From: Len Brown
>
> Linux suspend-to-RAM was unreliable when first developed,
> and so sys_sync() was invoked inside the kernel at the
> start of every suspend flow.
>
> Today, many devices are invoking suspend with
> high reliability and hig
From: Len Brown
Linux suspend-to-RAM was unreliable when first developed,
and so sys_sync() was invoked inside the kernel at the
start of every suspend flow.
Today, many devices are invoking suspend with
high reliability and high frequency, and they don't
want to be forced to pay for sync on eve
25 matches
Mail list logo
