On Tue, Sep 19, 2006 at 01:10:36PM +0200, Rafael J. Wysocki wrote:
> > Ok, but these are improvements for userspace suspend, not for in-kernel?
>
> No, they are for in-kernel. :-)
Good. Then i'll skip them. I already have enough to do to not waste my time
with obsolete technology :-)
--
Stefan
On Tuesday, 19 September 2006 04:40, Stefan Seyfried wrote:
> On Mon, Sep 18, 2006 at 10:37:01PM +0200, Rafael J. Wysocki wrote:
> > On Monday, 18 September 2006 18:32, Stefan Seyfried wrote:
> > >
> > > > > It also was always dog slow with in-kernel suspend.
> > > >
> > > > Have you tried the la
On Tuesday, 19 September 2006 08:29, Pavel Machek wrote:
> On Mon 2006-09-18 22:37:39, Rafael J. Wysocki wrote:
> > On Monday, 18 September 2006 21:48, Pavel Machek wrote:
> > > Hi!
> > > >
> > > > I have not benchmarked it really exact, so i'm not sure. However,
> > > > resume is
> > > > much fa
On Mon 2006-09-18 22:37:39, Rafael J. Wysocki wrote:
> On Monday, 18 September 2006 21:48, Pavel Machek wrote:
> > Hi!
> > >
> > > I have not benchmarked it really exact, so i'm not sure. However, resume
> > > is
> > > much faster and without flickering disk light.
> >
> > I have strange feeling
On Mon, Sep 18, 2006 at 10:37:01PM +0200, Rafael J. Wysocki wrote:
> On Monday, 18 September 2006 18:32, Stefan Seyfried wrote:
> >
> > > > It also was always dog slow with in-kernel suspend.
> > >
> > > Have you tried the latest -mm?
> >
> > No. Should i?
>
> It contains some patches that shou
On Monday, 18 September 2006 21:48, Pavel Machek wrote:
> Hi!
> >
> > I have not benchmarked it really exact, so i'm not sure. However, resume is
> > much faster and without flickering disk light.
>
> I have strange feeling we have bug somewhere... like kacpid looping
> and eating 100% cpu.
Why
On Monday, 18 September 2006 18:32, Stefan Seyfried wrote:
> On Mon, Sep 18, 2006 at 05:10:14PM +0200, Rafael J. Wysocki wrote:
>
> > > compression enabled, i get a flickering disk led during write, without it
> > > is solid on. Since it is a Pentium M 1400, CPU speed should be fast enough
> > > t
Hi!
>
> I have not benchmarked it really exact, so i'm not sure. However, resume is
> much faster and without flickering disk light.
I have strange feeling we have bug somewhere... like kacpid looping
and eating 100% cpu.
Can you try remounting everything r/o, placing exec('/bin/bash') at
the en
On Mon, Sep 18, 2006 at 05:10:14PM +0200, Rafael J. Wysocki wrote:
> > compression enabled, i get a flickering disk led during write, without it
> > is solid on. Since it is a Pentium M 1400, CPU speed should be fast enough
> > to benefit from compression.
>
> Well, what kind of RAM is there is t
On Monday, 18 September 2006 16:02, Jason Lunz wrote:
> On Mon, Sep 18, 2006 at 01:10:45PM +0200, Tim Dijkstra wrote:
> > > It would be nice to actually benchmark this, and hardcode the option that
> > > provides acceptable performance...
> >
> > Sure, maybe Jason can provide some numbers.
>
> y
On Monday, 18 September 2006 13:02, Stefan Seyfried wrote:
> On Mon, Sep 18, 2006 at 12:01:05PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > I think performance shouldn't be hurt, since we're still batching
> > > > pages 1% at a time, down from 20%. A normal image has 10's of
> > > > thousands o
[EMAIL PROTECTED] said:
> Hmm.. we can probably do that. Is smoothly-running progressbar really
> all that important?
it is to me. That's why I wrote the patch, because I got tired of
looking at inaccurate progress output. And I don't use splash.
I agree about correctness, but this *is* correct.
On Mon, Sep 18, 2006 at 01:10:45PM +0200, Tim Dijkstra wrote:
> > It would be nice to actually benchmark this, and hardcode the option that
> > provides acceptable performance...
>
> Sure, maybe Jason can provide some numbers.
yeah, i'll whip up a writeout-timing patch tonight. That might be use
On Mon, 18 Sep 2006 13:27:19 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Monday, 18 September 2006 13:17, Pavel Machek wrote:
> > > > "It is an option, so it is not important to get it right" is
> > > > ugly. It would be nice to actually benchmark this,
> > >
> > > Agreed.
On Mon, Sep 18, 2006 at 12:01:05PM +0200, Pavel Machek wrote:
> Hi!
>
> > > I think performance shouldn't be hurt, since we're still batching
> > > pages 1% at a time, down from 20%. A normal image has 10's of
> > > thousands of pages (mine 512M laptop is ~55000 pages, for example) so
> > > 1% is
Hi,
On Monday, 18 September 2006 13:17, Pavel Machek wrote:
> > > "It is an option, so it is not important to get it right" is ugly. It
> > > would be nice to actually benchmark this,
> >
> > Agreed.
> >
> > > and hardcode the option that provides acceptable performance...
> >
> > That would be
Hi!
> > "It is an option, so it is not important to get it right" is ugly. It
> > would be nice to actually benchmark this,
>
> Agreed.
>
> > and hardcode the option that provides acceptable performance...
>
> That would be difficult, because it changes substantially from one machine
> to anoth
On Mon, 18 Sep 2006 12:01:05 +0200
Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > > I think performance shouldn't be hurt, since we're still batching
> > > pages 1% at a time, down from 20%. A normal image has 10's of
> > > thousands of pages (mine 512M laptop is ~55000 pages, for example) s
Hi,
On Monday, 18 September 2006 12:01, Pavel Machek wrote:
> > > I think performance shouldn't be hurt, since we're still batching
> > > pages 1% at a time, down from 20%. A normal image has 10's of
> > > thousands of pages (mine 512M laptop is ~55000 pages, for example) so
> > > 1% is still~500
Hi!
> > I think performance shouldn't be hurt, since we're still batching
> > pages 1% at a time, down from 20%. A normal image has 10's of
> > thousands of pages (mine 512M laptop is ~55000 pages, for example) so
> > 1% is still~500 pages or ~2M at a time.
>
> I don't know to if it would impact
On Sun, 17 Sep 2006 20:05:29 -0400
Jason Lunz <[EMAIL PROTECTED]> wrote:
>
> Increase the granularity of calls to start_writeout() when
> early_writeout is used. This results in a smooth progress display
> during writeout, rather than a noticeable pause each 20% of the way
> through.
Yes, I noti
Increase the granularity of calls to start_writeout() when
early_writeout is used. This results in a smooth progress display during
writeout, rather than a noticeable pause each 20% of the way through.
I think performance shouldn't be hurt, since we're still batching pages
1% at a time, down from
22 matches
Mail list logo
