Re: 2.6.9-rc2-mm1 swsusp bug report.

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Pascal Schmidt]

On Sat, 25 Sep 2004 01:50:08 +0200, you wrote in linux.kernel:

> The problem isn't really that you're out of memory. Rather, the memory
> is so fragmented that swsusp is unable to get an order 8 allocation in
> which to store its metadata. There isn't really anything you can do to
> avoid this issue apart from eating memory (which swsusp is doing
> anyway).

That's one megabyte, right? Can't we preallocate that on boot, while
there's still chance to get that much contiguous memory? If the
user has swsusp compiled into his kernel, he probably wants it to
function, so it's not really "wasted".

-- 
Ciao,
Pascal

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Pavel Machek]

Hi!

> > The problem isn't really that you're out of memory. Rather, the memory
> > is so fragmented that swsusp is unable to get an order 8 allocation in
> > which to store its metadata. There isn't really anything you can do to
> > avoid this issue apart from eating memory (which swsusp is doing
> > anyway).
> 
> That's one megabyte, right? Can't we preallocate that on boot, while
> there's still chance to get that much contiguous memory? If the
> user has swsusp compiled into his kernel, he probably wants it to
> function, so it's not really "wasted".

You do not know how much you should preallocate, because it depends on
ammount of memory used. You could preallocate maximum possible
ammount...

OTOH this is first report of this failure. If it fails once in a blue
moon, it is probably better to let it fail than waste memory.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Jan Rychter]

>>>>> "Pavel" == Pavel Machek <pavel@ucw.cz> writes:
 Pavel> Hi!
 > The problem isn't really that you're out of memory. Rather, the
 > memory is so fragmented that swsusp is unable to get an order 8
 > allocation in which to store its metadata. There isn't really
 > anything you can do to avoid this issue apart from eating memory
 > (which swsusp is doing anyway).
 >>
 >> That's one megabyte, right? Can't we preallocate that on boot, while
 >> there's still chance to get that much contiguous memory? If the user
 >> has swsusp compiled into his kernel, he probably wants it to
 >> function, so it's not really "wasted".

 Pavel> You do not know how much you should preallocate, because it
 Pavel> depends on ammount of memory used. You could preallocate maximum
 Pavel> possible ammount...

 Pavel> OTOH this is first report of this failure. If it fails once in a
 Pavel> blue moon, it is probably better to let it fail than waste
 Pavel> memory.

This is *exactly* why I choose to use swsusp2. There is a marked
difference in the maintainer's approach to these kinds of problems.

The net result is that swsusp2 has worked for me very well for many
months now: I have been suspending and resuming happily for several
months, with exactly 0 swsusp-caused crashes or failures.

BTW, on a related note, I believe there is too much acceptance for
crashes and failures in the Linux world recently. Take an example: I can
bring down any of my machines (kernels 2.4 or 2.6) in less than 10
minutes just by plugging in and unplugging USB devices. There is
something fundamentally wrong with the USB subsystem if it is possible
to do that.

--J.

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Stefan Seyfried]

Hi,

Pavel Machek wrote:

> OTOH this is first report of this failure. If it fails once in a blue
> moon, it is probably better to let it fail than waste memory.

PM: Attempting to suspend to disk.
PM: snapshotting memory.
swsusp: critical section:
swsusp: Saving Highmem
[nosave pfn 0x3be]<7>[nosave pfn 0x3bf]swsusp: Need to copy 30519 pages
suspend: (pages needed: 30519 + 512 free: 100469)
do_acpi_sleep: page allocation failure. order:7, mode:0x120
 [<c013a628>] __alloc_pages+0x3a8/0x3b0
 [<c013a648>] __get_free_pages+0x18/0x30
 [<c0132c37>] alloc_pagedir+0x17/0x60
 [<c0132ddb>] swsusp_alloc+0x4b/0xa0
 [<c0132e63>] suspend_prepare_image+0x33/0x80
 [<c028beda>] swsusp_arch_suspend+0x2a/0x30
 [<c0132f1b>] swsusp_suspend+0x2b/0x40
 [<c01332ad>] pm_suspend_disk+0x3d/0xb0
 [<c0131765>] enter_state+0x85/0x90
 [<c01318b1>] state_store+0xc1/0xc3
 [<c01317f0>] state_store+0x0/0xc3
 [<c01852e6>] subsys_attr_store+0x26/0x30
 [<c018548d>] flush_write_buffer+0x1d/0x30
 [<c01854c9>] sysfs_write_file+0x29/0x40
 [<c01854a0>] sysfs_write_file+0x0/0x40
 [<c0150c7f>] vfs_write+0x9f/0x100
 [<c0150d8c>] sys_write+0x3c/0x70
 [<c0105c69>] sysenter_past_esp+0x52/0x79
suspend: Allocating pagedir failed.
swsusp: Restoring Highmem

this happened right now, after running fine over the weekend and doing a
successful suspend/resume cycle this morning.
It was a "battery critical" suspend, so this is not nice :-( I had about
2 minutes left until hard powerdown during which i tried to get it to
suspend but failed. Yes, userspace should handle the "failed
battery-critical suspend" case better and probably call "shutdown -h now".

      Stefan

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Pavel Machek]

Hi!

>  Pavel> You do not know how much you should preallocate, because it
>  Pavel> depends on ammount of memory used. You could preallocate maximum
>  Pavel> possible ammount...
> 
>  Pavel> OTOH this is first report of this failure. If it fails once in a
>  Pavel> blue moon, it is probably better to let it fail than waste
>  Pavel> memory.
> 
> This is *exactly* why I choose to use swsusp2. There is a marked
> difference in the maintainer's approach to these kinds of problems.

Okay, and do you have something to say or do you want to start
flamewar? That is also why swsusp2 is 10 times code size of swsusp...

								Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Jan Rychter]

>>>>> "Pavel" == Pavel Machek <pavel@ucw.cz> writes:
 Pavel> Hi!  You do not know how much you should preallocate, because it
 Pavel> depends on ammount of memory used. You could preallocate maximum
 Pavel> possible ammount...
 >>
 Pavel> OTOH this is first report of this failure. If it fails once in a
 Pavel> blue moon, it is probably better to let it fail than waste
 Pavel> memory.
 >>
 >> This is *exactly* why I choose to use swsusp2. There is a marked
 >> difference in the maintainer's approach to these kinds of problems.

 Pavel> Okay, and do you have something to say or do you want to start
 Pavel> flamewar? That is also why swsusp2 is 10 times code size of
 Pavel> swsusp...

Sure, flame me if you think this is the right thing to do. But I will
continue to pitch in with a users' opinion sometimes, because I really
believe it is important.

It is easy to lose sight of the user perspective on these things if all
you deal with is kernel development. You probably reboot your machine
dozens of times a day anyway. However, for some users crashes and
reboots are *very* expensive. These people (myself included) consider
sprinkling the code with panics, crashing and failing an unacceptable
thing to do.

I also believe your reply shows how important it is for me to actually
write things like these from time to time (even risking getting
flamed). As a user I don't care whatsoever what the code size
is. Actually, I don't care that much about its performance, either. What
I do care about is that my operating system doesn't crash from under me,
doesn't lose my data, and doesn't fail on me with suspending when I
really need it to suspend now. Give me a userspace USB implementation
that works 10x slower and is 10x larger but doesn't crash my machine and
I'll take it any day.

--J.

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Pavel Machek]

Hi!

> > OTOH this is first report of this failure. If it fails once in a blue
> > moon, it is probably better to let it fail than waste memory.
> 
> PM: Attempting to suspend to disk.
> PM: snapshotting memory.
> swsusp: critical section:
> swsusp: Saving Highmem
> [nosave pfn 0x3be]<7>[nosave pfn 0x3bf]swsusp: Need to copy 30519 pages
> suspend: (pages needed: 30519 + 512 free: 100469)
> do_acpi_sleep: page allocation failure. order:7, mode:0x120
>  [<c013a628>] __alloc_pages+0x3a8/0x3b0
>  [<c013a648>] __get_free_pages+0x18/0x30
>  [<c0132c37>] alloc_pagedir+0x17/0x60
>  [<c0132ddb>] swsusp_alloc+0x4b/0xa0
>  [<c0132e63>] suspend_prepare_image+0x33/0x80
>  [<c028beda>] swsusp_arch_suspend+0x2a/0x30
>  [<c0132f1b>] swsusp_suspend+0x2b/0x40
>  [<c01332ad>] pm_suspend_disk+0x3d/0xb0
>  [<c0131765>] enter_state+0x85/0x90
>  [<c01318b1>] state_store+0xc1/0xc3
>  [<c01317f0>] state_store+0x0/0xc3
>  [<c01852e6>] subsys_attr_store+0x26/0x30
>  [<c018548d>] flush_write_buffer+0x1d/0x30
>  [<c01854c9>] sysfs_write_file+0x29/0x40
>  [<c01854a0>] sysfs_write_file+0x0/0x40
>  [<c0150c7f>] vfs_write+0x9f/0x100
>  [<c0150d8c>] sys_write+0x3c/0x70
>  [<c0105c69>] sysenter_past_esp+0x52/0x79
> suspend: Allocating pagedir failed.
> swsusp: Restoring Highmem
> 
> this happened right now, after running fine over the weekend and doing a
> successful suspend/resume cycle this morning.
> It was a "battery critical" suspend, so this is not nice :-( I had about
> 2 minutes left until hard powerdown during which i tried to get it to
> suspend but failed. Yes, userspace should handle the "failed
> battery-critical suspend" case better and probably call "shutdown -h now".

Ok... And I guess it is nearly impossible to trigger this on demand,
right?

I do not think I can use vmalloc easily because reallocate_pagedir
depends on it being contiguous.. Switching to link list is "just a
simple matter of coding", but it is going to be quite a lot of
changes.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Stefan Seyfried]

Hi,

Pavel Machek wrote:

> Ok... And I guess it is nearly impossible to trigger this on demand,
> right?

Of course. I just wanted to say "yes, it does happen". I did not say
fixing it would be easy ;-)

    Stefan

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Rafael J. Wysocki]

On Monday 11 of October 2004 19:18, Stefan Seyfried wrote:
> Hi,
> 
> Pavel Machek wrote:
> 
> > Ok... And I guess it is nearly impossible to trigger this on demand,
> > right?

I think it is possible.  Seemingly, on my box it's only a question of the 
number of apps started.  I think I can work out a method to trigger it 90% of 
the time or so.  Please let me know if it's worthy of doing.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Pavel Machek]

Hi!

> > > Ok... And I guess it is nearly impossible to trigger this on demand,
> > > right?
> 
> I think it is possible.  Seemingly, on my box it's only a question of the 
> number of apps started.  I think I can work out a method to trigger it 90% of 
> the time or so.  Please let me know if it's worthy of doing.

Yes, it would certainly help with testing...
									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Rafael J. Wysocki]

On Tuesday 12 of October 2004 10:55, Pavel Machek wrote:
> Hi!
> 
> > > > Ok... And I guess it is nearly impossible to trigger this on demand,
> > > > right?
> > 
> > I think it is possible.  Seemingly, on my box it's only a question of the 
> > number of apps started.  I think I can work out a method to trigger it
> > 90% of the time or so.  Please let me know if it's worthy of doing.
> 
> Yes, it would certainly help with testing...

So far, the most reliable method seems to be to use the box for a day after a 
successful suspend/resume cycle (I've got an 8-order allocation failure 3 
times out of 3 attempts).  Still, I'm working on something that's less 
time-consuming. ;-)

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

swsusp: 8-order allocation failure on demand (was: Re: 2.6.9-rc2-mm1 swsusp bug report.)

[Rafael J. Wysocki]

On Wednesday 13 of October 2004 19:29, Rafael J. Wysocki wrote:
> On Tuesday 12 of October 2004 10:55, Pavel Machek wrote:
> > Hi!
> > 
> > > > > Ok... And I guess it is nearly impossible to trigger this on demand,
> > > > > right?
> > > 
> > > I think it is possible.  Seemingly, on my box it's only a question of 
the 
> > > number of apps started.  I think I can work out a method to trigger it
> > > 90% of the time or so.  Please let me know if it's worthy of doing.
> > 
> > Yes, it would certainly help with testing...

Well, I can do that, it seems, 100% of the time.

The method is to do "init 5" (my default runlevel is 3, because vts become 
unreadable after I start X), log into KDE (as a non-root), start some X apps 
at random (eg. I run gkrellm, kmail, konqueror, Mozilla FireFox 32-bit w/ 
Flash plugin, and konsole with "su -") and run updatedb (as root, of course).

Apparently, running updatedb is essential.  After it finishes, on my box, you 
can forget of suspending to disk from under the X+KDE combo, even if the X 
apps (ie. kmail, konqueror, FireFox) are stopped before.  However, if 
updatedb is not run, the box usually suspends successfully.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: 8-order allocation failure on demand (update)

[Rafael J. Wysocki]

On Thursday 14 of October 2004 23:47, Rafael J. Wysocki wrote:
> On Wednesday 13 of October 2004 19:29, Rafael J. Wysocki wrote:
> > On Tuesday 12 of October 2004 10:55, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > > > Ok... And I guess it is nearly impossible to trigger this on 
demand,
> > > > > > right?
> > > > 
> > > > I think it is possible.  Seemingly, on my box it's only a question of 
> the 
> > > > number of apps started.  I think I can work out a method to trigger it
> > > > 90% of the time or so.  Please let me know if it's worthy of doing.
> > > 
> > > Yes, it would certainly help with testing...
> 
> Well, I can do that, it seems, 100% of the time.
> 
> The method is to do "init 5" (my default runlevel is 3, because vts become 
> unreadable after I start X), log into KDE (as a non-root), start some X apps 
> at random (eg. I run gkrellm, kmail, konqueror, Mozilla FireFox 32-bit w/ 
> Flash plugin, and konsole with "su -") and run updatedb (as root, of
> course). 

To be precise, the method always leads to a failure, but it seems to be either 
8-order or 9-order page allocation failure.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: 8-order allocation failure on demand (update)

[Pavel Machek]

Hi!

> > > > > > > Ok... And I guess it is nearly impossible to trigger this on 
> demand,
> > > > > > > right?
> > > > > 
> > > > > I think it is possible.  Seemingly, on my box it's only a question of 
> > the 
> > > > > number of apps started.  I think I can work out a method to trigger it
> > > > > 90% of the time or so.  Please let me know if it's worthy of doing.
> > > > 
> > > > Yes, it would certainly help with testing...
> > 
> > Well, I can do that, it seems, 100% of the time.
> > 
> > The method is to do "init 5" (my default runlevel is 3, because vts become 
> > unreadable after I start X), log into KDE (as a non-root), start some X apps 
> > at random (eg. I run gkrellm, kmail, konqueror, Mozilla FireFox 32-bit w/ 
> > Flash plugin, and konsole with "su -") and run updatedb (as root, of
> > course). 
> 
> To be precise, the method always leads to a failure, but it seems to be either 
> 8-order or 9-order page allocation failure.

Okay, you could probably pre-allocate 512K block during bootup, then
just use that instead of allocating new one during suspend.

Unfortunately that's rather ugly. You'd ~32 bytes per 4K page, that's
almost 1% overhead, not nice. Better solution (but more work) is to
switch to link-lists or integrate swsusp2.
									Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.

Re: swsusp: 8-order allocation failure on demand (update)

[Rafael J. Wysocki]

On Saturday 16 of October 2004 18:43, Pavel Machek wrote:
> Hi!
> 
> > > > > > > > Ok... And I guess it is nearly impossible to trigger this on 
> > > > > > > > demand, right?
> > > > > > 
> > > > > > I think it is possible.  Seemingly, on my box it's only a question 
> > > > > > of the number of apps started.  I think I can work out a method
> > > > > > to trigger it 90% of the time or so.  Please let me know if it's
> > > > > > worthy of doing. 
> > > > > 
> > > > > Yes, it would certainly help with testing...
> > > 
> > > Well, I can do that, it seems, 100% of the time.
> > > 
> > > The method is to do "init 5" (my default runlevel is 3, because vts
> > > become unreadable after I start X), log into KDE (as a non-root),
> > > start some X apps at random (eg. I run gkrellm, kmail, konqueror,
> > > Mozilla FireFox 32-bit w/ Flash plugin, and konsole with "su -") and
> > > run updatedb (as root, of course). 
> > 
> > To be precise, the method always leads to a failure, but it seems to
> > be either 8-order or 9-order page allocation failure.
> 
> Okay, you could probably pre-allocate 512K block during bootup, then
> just use that instead of allocating new one during suspend.
> 
> Unfortunately that's rather ugly. You'd ~32 bytes per 4K page, that's
> almost 1% overhead, not nice. Better solution (but more work) is to
> switch to link-lists or integrate swsusp2.

Well, I wonder if the page allocation failures are a swsusp problem, really.  
I've just tried it the other way around and ran updatedb _first_, then 
started X+KDE (no additional apps) and tried to suspend from under it.  Guess 
what: a 9-order page allocation failure, here you go.

It seems to me that updatedb leaves a mess in memory, which IMO should not 
happen or at least the kernel should be able to clean it, but apparently it 
is not.  I'd be grateful if someone could explain to me why that is so, 
please.

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: 8-order allocation failure on demand (update)

[Pavel Machek]

Hi!

> > Unfortunately that's rather ugly. You'd ~32 bytes per 4K page, that's
> > almost 1% overhead, not nice. Better solution (but more work) is to
> > switch to link-lists or integrate swsusp2.
> 
> Well, I wonder if the page allocation failures are a swsusp problem,
> really.  

Yes, they are. Kernel memory allocation is not design to do 8-order
allocations properly. swsusp really should not use them.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: swsusp: 8-order allocation failure on demand (update)

[Rafael J. Wysocki]

On Saturday 16 of October 2004 22:40, Pavel Machek wrote:
> Hi!
> 
> > > Unfortunately that's rather ugly. You'd ~32 bytes per 4K page, that's
> > > almost 1% overhead, not nice. Better solution (but more work) is to
> > > switch to link-lists or integrate swsusp2.
> > 
> > Well, I wonder if the page allocation failures are a swsusp problem,
> > really.  
> 
> Yes, they are. Kernel memory allocation is not design to do 8-order
> allocations properly. swsusp really should not use them.

Now that's clear, thanks.  Could you tell me, please, what I need to know to 
understand the swsusp code and what I should start with?

Greets,
RJW

-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

Re: swsusp: 8-order allocation failure on demand (update)

[Pavel Machek]

Hi!

> > > > Unfortunately that's rather ugly. You'd ~32 bytes per 4K page, that's
> > > > almost 1% overhead, not nice. Better solution (but more work) is to
> > > > switch to link-lists or integrate swsusp2.
> > > 
> > > Well, I wonder if the page allocation failures are a swsusp problem,
> > > really.  
> > 
> > Yes, they are. Kernel memory allocation is not design to do 8-order
> > allocations properly. swsusp really should not use them.
> 
> Now that's clear, thanks.  Could you tell me, please, what I need to know to 
> understand the swsusp code and what I should start with?

On bootup, prealloc, say, order-9 alocation.

In alloc_pagedir(), do not allocate anything, but check that data fit
in preallocated area, and fail if not.

There's free_pages( pagedir_save, ...) somewhere, remove that so
pagedir is never freed and you can resume multiple times.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Pavel Machek]

Hi!

> Sure, flame me if you think this is the right thing to do. But I will
> continue to pitch in with a users' opinion sometimes, because I really
> believe it is important.
> 
> It is easy to lose sight of the user perspective on these things if all
> you deal with is kernel development. You probably reboot your machine
> dozens of times a day anyway. However, for some users crashes and
> reboots are *very* expensive. These people (myself included) consider
> sprinkling the code with panics, crashing and failing an unacceptable
> thing to do.

You can have code that does not panic, does not crash, does not
corrupt your data, never fails to suspend and is in Linus' tree.

...no, that is too good. It sounds like a fairy tale.

So pick any four.
								Pavel

PS: And it is real. We have conflicting goals here and I consider
"refuses to suspend" least critical.
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: 2.6.9-rc2-mm1 swsusp bug report.

[Nigel Cunningham]

Hi.

On Mon, 2004-10-18 at 05:10, Pavel Machek wrote:
> You can have code that does not panic, does not crash, does not
> corrupt your data, never fails to suspend and is in Linus' tree.
> 
> ...no, that is too good. It sounds like a fairy tale.
> 
> So pick any four.
> 								Pavel
> 
> PS: And it is real. We have conflicting goals here and I consider
> "refuses to suspend" least critical.

I'm going for all five! You're probably right, nevertheless. I can't say
suspend2 _never_ fails to suspend. It's just very rare.

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.