Hi,
On Friday, 20 July 2007 19:56, Alon Bar-Lev wrote:
>
> Hello Rafael,
>
> Yet another patch in the suspend2 feature-set series.
> It sets cpufreq to maximum during the cycle.
> It is important to finish the process as quickly as possible (human engineer
> issue :) )
> When running on batteri
On Fri, Jul 27, 2007 at 05:48:52PM +0300, Alon Bar-Lev wrote:
> On 7/27/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> > On Sun, Jul 22, 2007 at 10:09:50PM +0300, Alon Bar-Lev wrote:
> > > > These s2ram_* funcs in the end call code from vbetool/vbetool.c which
> > > > is indeed linked in. But par
On Fri, Jul 27, 2007 at 05:52:15PM +0300, Alon Bar-Lev wrote:
> On 7/27/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> > On Mon, Jul 23, 2007 at 11:25:10AM +0200, Pavel Machek wrote:
> >
> > > Well, so user explicitely configured his machine to run on 80% max,
> > > for some reason. Now you want
On 7/27/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 23, 2007 at 11:25:10AM +0200, Pavel Machek wrote:
>
> > Well, so user explicitely configured his machine to run on 80% max,
> > for some reason. Now you want suspend to explicitely override his
> > setting. That strikes me as a ba
On Sat, Jul 21, 2007 at 06:28:24PM +0300, Alon Bar-Lev wrote:
> On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> > This is already done in pm-utils. Upstream uses 'userspace' as governor,
> > which I personally think is wrong. openSUSE uses the 'performance'
> > governor and this only because
On 7/27/07, Stefan Seyfried <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 22, 2007 at 10:09:50PM +0300, Alon Bar-Lev wrote:
> > > These s2ram_* funcs in the end call code from vbetool/vbetool.c which
> > > is indeed linked in. But partly I remembered it wrongly. The hacks
> > > _before_ suspend are call
On Mon, Jul 23, 2007 at 11:25:10AM +0200, Pavel Machek wrote:
> Well, so user explicitely configured his machine to run on 80% max,
> for some reason. Now you want suspend to explicitely override his
> setting. That strikes me as a bad idea. Plus it does not belong to
> suspend.
100% ACK
--
Stef
On Sun, Jul 22, 2007 at 10:09:50PM +0300, Alon Bar-Lev wrote:
> > These s2ram_* funcs in the end call code from vbetool/vbetool.c which
> > is indeed linked in. But partly I remembered it wrongly. The hacks
> > _before_ suspend are called with an unfrozen userspace, those after on
> > a frozen user
On Sat, Jul 21, 2007 at 11:08:30PM +0300, Alon Bar-Lev wrote:
> On 7/21/07, Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
> > On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> > > Right. So if we start putting things like cpufreq in the suspend package,
> > > we would have an argumentation to put eve
On Sat, Jul 21, 2007 at 09:01:03AM +0300, Alon Bar-Lev wrote:
> On 7/21/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> > On Fri, 20 Jul 2007 22:20:51 +0200
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > > > Yet another patch in the suspend2 feature-set series.
> > > > It sets cpufreq to
Sorry for coming late to the party...
On Fri, Jul 20, 2007 at 08:56:15PM +0300, Alon Bar-Lev wrote:
>
> Hello Rafael,
>
> Yet another patch in the suspend2 feature-set series.
> It sets cpufreq to maximum during the cycle.
> It is important to finish the process as quickly as possible (human eng
On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> But you explicitely configured your system to do that... so you get
> what you asked for. (And on very old systems, running at 80% cpu
> during suspend _could_ be a win, power-wise).
The 80% is configured with expectation of continue execution.
On Mon 2007-07-23 23:16:00, Alon Bar-Lev wrote:
> On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >> It works correctly now.
> >> Previously it did not work because of SIGALARM and related issues.
> >> I worked with cpufreqd developer to solve all these.
> >
> >Do you mean that cpufreqd is ru
On Mon 2007-07-23 20:17:40, Alon Bar-Lev wrote:
> On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >Well, so user explicitely configured his machine to run on 80% max,
> >for some reason. Now you want suspend to explicitely override his
> >setting. That strikes me as a bad idea. Plus it does n
On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > It works correctly now.
> > Previously it did not work because of SIGALARM and related issues.
> > I worked with cpufreqd developer to solve all these.
>
> Do you mean that cpufreqd is running while we suspend? That would be a
> serious bug. B
On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > They can...
> > There is no difference between doing:
> > vbe -> s2disk -> s2ram -> vbe
> > s2disk -> vbe -> s2ram -> vbe
>
> No. vbe data need to go unswappable memory, so we can display messages
> in case of something breaks etc... and passi
On Mon 2007-07-23 20:21:17, Alon Bar-Lev wrote:
> On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >> These s2ram_* funcs in the end call code from vbetool/vbetool.c which
> >> is indeed linked in. But partly I remembered it wrongly. The hacks
> >> _before_ suspend are called with an unfrozen
On Mon 2007-07-23 20:19:22, Alon Bar-Lev wrote:
> On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >Okay, so this is done from userland, not from kernel.
> >
> >Does cpu frequency scaling work properly after we snapshot the system?
> >If yes, we should not need to do this.
> >If not, this is u
On Mon 2007-07-23 20:14:15, Alon Bar-Lev wrote:
> On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >> So these hacks can be removed from suspend code... And moved into the
> >> hibernate-script or pm-utils.
> >
> >No, they can't (easily?), because of suspend-to-both. We want to
> >suspend-to-d
On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > These s2ram_* funcs in the end call code from vbetool/vbetool.c which
> > is indeed linked in. But partly I remembered it wrongly. The hacks
> > _before_ suspend are called with an unfrozen userspace, those after on
>
> We probably want to fix
On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Okay, so this is done from userland, not from kernel.
>
> Does cpu frequency scaling work properly after we snapshot the system?
> If yes, we should not need to do this.
> If not, this is unsafe.
> Which case is it?
>
> We may need to fix cpufre
On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Well, so user explicitely configured his machine to run on 80% max,
> for some reason. Now you want suspend to explicitely override his
> setting. That strikes me as a bad idea. Plus it does not belong to
> suspend.
The lower maximum is intende
On 7/23/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > So these hacks can be removed from suspend code... And moved into the
> > hibernate-script or pm-utils.
>
> No, they can't (easily?), because of suspend-to-both. We want to
> suspend-to-disk, and then (with frozen system) proceed with
> suspen
On Sun 2007-07-22 22:09:50, Alon Bar-Lev wrote:
> On 7/22/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> > On Sun, 22 Jul 2007 07:46:40 +0300
> > "Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:
> >
> > > On 7/21/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> > > > No. The vbetool code is linked in. It does
Hi!
> > > No. The vbetool code is linked in. It doesn't run as regular processes.
> > > At the time we do those hacks, we are the only not-frozen part of
> > > userspace.
> > > This is what makes it different from running it from a bunch of scripts.
> >
> > Are you sure?
> > Can you please refer
On Sat 2007-07-21 16:18:57, Alon Bar-Lev wrote:
> On 7/21/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > I'm not sure it is good idea. We should either let cpu frequency
> > scaling do its job during suspend (it should just scale to the max
> > when it sees cpu load), or force it to _minimum_. Mac
Hi!
> > some battery life. But imho it is better to test it first, maybe the
> > ondemand
> > govenor is even better.
>
> You may have a configuration in which ondemand can be in range of
> minimum to X, where X In this configuration letting the ondemand handle this will not result
> in optimum
On Sat 2007-07-21 11:50:01, Pavel Machek wrote:
> Hi!
>
> > > Hello Rafael,
> >
> > Thanks for all of the patches so far. :-)
> >
> > > Yet another patch in the suspend2 feature-set series.
> > > It sets cpufreq to maximum during the cycle.
> > > It is important to finish the process as quickly
On 7/22/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> On Sun, 22 Jul 2007 07:46:40 +0300
> "Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:
>
> > On 7/21/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> > > No. The vbetool code is linked in. It doesn't run as regular processes.
> > > At the time we do those
On Sun, 22 Jul 2007 07:46:40 +0300
"Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:
> On 7/21/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> > No. The vbetool code is linked in. It doesn't run as regular processes.
> > At the time we do those hacks, we are the only not-frozen part of userspace.
> > This i
On 7/21/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> No. The vbetool code is linked in. It doesn't run as regular processes.
> At the time we do those hacks, we are the only not-frozen part of userspace.
> This is what makes it different from running it from a bunch of scripts.
Are you sure?
Can
On Sat, 21 Jul 2007 23:08:30 +0300
"Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:
> On 7/21/07, Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
> > On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> > > Right. So if we start putting things like cpufreq in the suspend package,
> > > we would have an argument
On 7/21/07, Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
> On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> > Right. So if we start putting things like cpufreq in the suspend package,
> > we would have an argumentation to put everything which is in pm-utils, the
> > hibernate script etc. to it. And
On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> Right. So if we start putting things like cpufreq in the suspend package,
> we would have an argumentation to put everything which is in pm-utils, the
> hibernate script etc. to it. And I don't think this is what we want.
You can put vbetool, r
On Sat 21. Jul - 18:28:24, Alon Bar-Lev wrote:
> On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> > This is already done in pm-utils. Upstream uses 'userspace' as governor,
> > which I personally think is wrong. openSUSE uses the 'performance'
> > governor and this only because of a bug in the
On Sat, 21 Jul 2007 18:28:24 +0300
"Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:
> On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> > This is already done in pm-utils. Upstream uses 'userspace' as governor,
> > which I personally think is wrong. openSUSE uses the 'performance'
> > governor and th
On 7/21/07, Holger Macht <[EMAIL PROTECTED]> wrote:
> This is already done in pm-utils. Upstream uses 'userspace' as governor,
> which I personally think is wrong. openSUSE uses the 'performance'
> governor and this only because of a bug in the kernel which caused the
> system to hang on suspend AF
On Sat 21. Jul - 01:24:51, Tim Dijkstra wrote:
> On Fri, 20 Jul 2007 22:20:51 +0200
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > > Yet another patch in the suspend2 feature-set series.
> > > It sets cpufreq to maximum during the cycle.
>
> I haven't looked at the patch, but this doesn't
On 7/21/07, Till Maas <[EMAIL PROTECTED]> wrote:
> some battery life. But imho it is better to test it first, maybe the ondemand
> govenor is even better.
You may have a configuration in which ondemand can be in range of
minimum to X, where X /proc/acpi/sony/brightness
profile=On Demand Low
[/Rule
On Saturday 21 July 2007 11:50:01 Pavel Machek wrote:
> I'm not sure it is good idea. We should either let cpu frequency
> scaling do its job during suspend (it should just scale to the max
> when it sees cpu load), or force it to _minimum_. Machines will
> overheat on max cpufreq, and they may ov
On 7/21/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> I'm not sure it is good idea. We should either let cpu frequency
> scaling do its job during suspend (it should just scale to the max
> when it sees cpu load), or force it to _minimum_. Machines will
> overheat on max cpufreq, and they may overl
Hi!
> > Hello Rafael,
>
> Thanks for all of the patches so far. :-)
>
> > Yet another patch in the suspend2 feature-set series.
> > It sets cpufreq to maximum during the cycle.
> > It is important to finish the process as quickly as possible (human
> > engineer issue :) )
> > When running on b
On 7/21/07, Tim Dijkstra <[EMAIL PROTECTED]> wrote:
> On Fri, 20 Jul 2007 22:20:51 +0200
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > > Yet another patch in the suspend2 feature-set series.
> > > It sets cpufreq to maximum during the cycle.
>
> I haven't looked at the patch, but this does
On Fri, 20 Jul 2007 22:20:51 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> > Yet another patch in the suspend2 feature-set series.
> > It sets cpufreq to maximum during the cycle.
I haven't looked at the patch, but this doesn't really sound essential
for uswsusp. Maybe it should go into
Hi,
On Friday, 20 July 2007 19:56, Alon Bar-Lev wrote:
>
> Hello Rafael,
Thanks for all of the patches so far. :-)
> Yet another patch in the suspend2 feature-set series.
> It sets cpufreq to maximum during the cycle.
> It is important to finish the process as quickly as possible (human engine
Hello Rafael,
Yet another patch in the suspend2 feature-set series.
It sets cpufreq to maximum during the cycle.
It is important to finish the process as quickly as possible (human engineer
issue :) )
When running on batteries it may take forever without this...
Please consider to apply.
If yo
46 matches
Mail list logo
