login
Search
What started as the review of a bug report grew into an interesting debate as Linus Torvalds slammed the current suspend and resume [story] design in the Linux Kernel, "why the HELL cannot you realize that kernel threads are different? The right thing to do is AND HAS ALWAYS BEEN, to stop and start user threads only around the whole thing. Don't touch those kernel threads. Stop freezing them." Later in the discussion, Linus noted that he had no interest in Suspend to Disk (STD), and was only interested in a working Suspend to Ram (STR) implementation. He noted that complexity introduced by STD was infecting the STR logic, and that the two should be completely separated, "what irritates me is that STR really shouldn't have _had_ that bug at all. The only reason STR had the same bug as STD was exactly the fact that the two features are too closely inter-twined in the kernel. That irritates me hugely. We had a bug we should never had had! We had a bug because people are sharing code that shouldn't be shared! We had a bug because of code that makes no sense in the first place!" Linus noted that he doesn't use laptops much, but still likes STR on his desktop, "STR means they are quiet and don't waste energy when I don't use them, but they're instantly available when I care." He then went on to point to design flaws in the freezer:
"I actually don't think that processes should be frozen really at all. I agree that filesystems have to be frozen (and I think that checkpointing of the filesystem or block device is 'too clever'), but I just don't think that has anything to do with freezing processes. So I'd actually much prefer to freeze at the VFS (and socket layers, etc), and make sure that anybody who tries to write or do something else that we cannot do until resuming, will just be blocked (or perhaps just buffered)!"
From: Linus Torvalds [email blocked] To: Romano Giannetti [email blocked] Subject: Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 09:16:10 -0700 (PDT) On Thu, 24 May 2007, Romano Giannetti wrote: > > I discovered that SysRq-t works during the pause. So I pressed it more > or less halfway the pause; the full result is here: > http://www.dea.icai.upcomillas.es/romano/linux/info/dmesg-resume.txt > > It seems that most of the tasks are in > > [<c0138931>] refrigerator+0x41/0x60 Yeah, but the interesting one is this pair: events/0 R running 0 4 1 (L-TLB) sleep.sh D 0000014F 0 5798 5789 (NOTLB) Call Trace: [<c01d3c01>] kobject_uevent_env+0x3a1/0x4a0 [<c02d8509>] wait_for_completion+0x79/0xb0 [<c0116640>] default_wake_function+0x0/0x10 [<c0238a08>] _request_firmware+0x1c8/0x310 [<c0238bef>] request_firmware+0xf/0x20 [<e0a35d5d>] pcmcia_bus_match+0x28d/0x3c0 [pcmcia] [<c02864a7>] netlink_broadcast+0x1f7/0x310 [<c0233d74>] driver_probe_device+0x34/0xc0 [<c02d79ee>] klist_next+0x4e/0xa0 [<c0233014>] bus_for_each_drv+0x44/0x70 [<c0233eba>] device_attach+0x7a/0x80 [<c0233e00>] __device_attach+0x0/0x10 [<c0232f56>] bus_attach_device+0x26/0x60 [<c0231d06>] device_add+0x5e6/0x6e0 [<c01d350f>] kobject_init+0x2f/0x50 [<e0a360f5>] pcmcia_device_add+0x185/0x220 [pcmcia] [<e0a36261>] pcmcia_card_add+0xa1/0xc0 [pcmcia] [<e0913900>] ti12xx_power_hook+0x180/0x1d0 [yenta_socket] [<e0a36300>] ds_event+0x80/0xb0 [pcmcia] [<e0967359>] send_event+0x39/0x70 [pcmcia_core] [<e09677b6>] socket_insert+0x86/0xe0 [pcmcia_core] [<e0967c2b>] pcmcia_socket_dev_resume+0x7b/0x90 [pcmcia_core] [<c01e135f>] pci_device_resume+0x1f/0x60 [<c023815f>] resume_device+0x5f/0xf0 ie we have a deadlock because resume wants to do that firmware request, but the event daemon is apparently spinning like mad. And yes, request_firmware() has a "loading_timeout" in seconds. And it's 60. So that explains your pause right there! It might be some unfortunate interaction with process freezing (my favorite whipping boy), but it could also be something else. I suspect we should treat suspend/resume as a bootup event, and not allow execve() for that case at all. Right now we have: retval = -EPERM; if (current->fs->root) retval = kernel_execve(sub_info->path, sub_info->argv, sub_info->envp); in kernel/kmod.c, and that "current->fs->root" thing basically protects us from trying to run a user-mode helper early in the boot sequence, but we might want to add a conditional like "&& !resuming" to that test.. Linus
From: Pavel Machek [email blocked] Subject: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 22:04:35 +0200 Hi! > Yeah, but the interesting one is this pair: > > events/0 R running 0 4 1 (L-TLB) > > sleep.sh D 0000014F 0 5798 5789 (NOTLB) > Call Trace: > [<c01d3c01>] kobject_uevent_env+0x3a1/0x4a0 > [<c02d8509>] wait_for_completion+0x79/0xb0 > [<c0116640>] default_wake_function+0x0/0x10 > [<c0238a08>] _request_firmware+0x1c8/0x310 > [<c0238bef>] request_firmware+0xf/0x20 > [<e0a35d5d>] pcmcia_bus_match+0x28d/0x3c0 [pcmcia] > [<c02864a7>] netlink_broadcast+0x1f7/0x310 > [<c0233d74>] driver_probe_device+0x34/0xc0 > [<c02d79ee>] klist_next+0x4e/0xa0 > [<c0233014>] bus_for_each_drv+0x44/0x70 > [<c0233eba>] device_attach+0x7a/0x80 > [<c0233e00>] __device_attach+0x0/0x10 > [<c0232f56>] bus_attach_device+0x26/0x60 > [<c0231d06>] device_add+0x5e6/0x6e0 > [<c01d350f>] kobject_init+0x2f/0x50 > [<e0a360f5>] pcmcia_device_add+0x185/0x220 [pcmcia] > [<e0a36261>] pcmcia_card_add+0xa1/0xc0 [pcmcia] > [<e0913900>] ti12xx_power_hook+0x180/0x1d0 [yenta_socket] > [<e0a36300>] ds_event+0x80/0xb0 [pcmcia] > [<e0967359>] send_event+0x39/0x70 [pcmcia_core] > [<e09677b6>] socket_insert+0x86/0xe0 [pcmcia_core] > [<e0967c2b>] pcmcia_socket_dev_resume+0x7b/0x90 [pcmcia_core] > [<c01e135f>] pci_device_resume+0x1f/0x60 > [<c023815f>] resume_device+0x5f/0xf0 > > ie we have a deadlock because resume wants to do that firmware request, > but the event daemon is apparently spinning like mad. > > And yes, request_firmware() has a "loading_timeout" in seconds. And > it's 60. So that explains your pause right there! If someone does request_firmware from resume function... that's bad. Resume function should be fixed. Pcmcia? ti12xx driver? > It might be some unfortunate interaction with process freezing (my > favorite whipping boy), but it could also be something else. I > suspect Well. we'd like to present hardware in working state as soon as we resume (if eth0 was there before resume, it should be there after resume. not 3 seconds after resume); so if someone needs to load the firmware, they should just store it in the kernel memory, and load it during boot or during (very early) suspend. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
From: Linus Torvalds [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 13:27:37 -0700 (PDT) On Thu, 24 May 2007, Pavel Machek wrote: > > If someone does request_firmware from resume function... that's > bad. Resume function should be fixed. Pcmcia? ti12xx driver? Probably pcmcia "ds" driver and CONFIG_PCMCIA_LOAD_CIS. > Well. we'd like to present hardware in working state as soon as we > resume (if eth0 was there before resume, it should be there after > resume. not 3 seconds after resume); so if someone needs to load the > firmware, they should just store it in the kernel memory, and load it > during boot or during (very early) suspend. Equally arguably, we should just have a "resume_late()" call that can be used to do this after everything is up and running. And quite frankly, I don't actually see any reason why firmware loading shouldn't work in the resume path. I really do think that this is ANOTHER bug that has no other reason than the fact that that f*cking freezer killed the system for no really good reason. Linus
From: Pavel Machek [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Fri, 25 May 2007 00:00:17 +0200 Hi! > > Well. we'd like to present hardware in working state as soon as we > > resume (if eth0 was there before resume, it should be there after > > resume. not 3 seconds after resume); so if someone needs to load the > > firmware, they should just store it in the kernel memory, and load it > > during boot or during (very early) suspend. > > Equally arguably, we should just have a "resume_late()" call that can be > used to do this after everything is up and running. Yes, we can do that. But userland will see devices "not there" for a few seconds after boot. ...that is ugly, but we can survive it for ethernet cards etc... but it will be really fatal for any block device. Pcmcia block devices exist, so I do not think we can do that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
From: Linus Torvalds [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 15:10:29 -0700 (PDT) On Fri, 25 May 2007, Pavel Machek wrote: > > > > Equally arguably, we should just have a "resume_late()" call that can be > > used to do this after everything is up and running. > > Yes, we can do that. But userland will see devices "not there" for a > few seconds after boot. No they won't. Why the HELL cannot you realize that kernel threads are different? The right thing to do is AND HAS ALWAYS BEEN, to stop and start user threads only around the whole thing. Don't touch those kernel threads. Stop freezing them. Then, what you do is: - stop user space - suspend - resume - start user space and at no point do you touch any kernel threads. And yes, that "resume" part is multi-phase. We already have "resume_early()" to do bus-level setup, and then "resume()" to do the "make devices work". I was suggesting adding a "resume_late()" phase to let the devices do things that require other devices to work, like doing firmware loading. But stopping kernel threads is STUPID. As long as we continue to do that, it will never _ever_ work. Yeah, we could re-start the kernel thread before "resume_late()", but the fact is, they shouldn't have been stopped in the first place. Linus
From: Pavel Machek [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Fri, 25 May 2007 00:17:43 +0200 On Thu 2007-05-24 15:10:29, Linus Torvalds wrote: > > > On Fri, 25 May 2007, Pavel Machek wrote: > > > > > > Equally arguably, we should just have a "resume_late()" call that can be > > > used to do this after everything is up and running. > > > > Yes, we can do that. But userland will see devices "not there" for a > > few seconds after boot. > > No they won't. > > Why the HELL cannot you realize that kernel threads are different? Ugh? We are talking about request_firmware() here, right? That's calling userland helper to load the firmware...? Looks like USER thread to me. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
From: Linus Torvalds [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 15:53:28 -0700 (PDT) On Fri, 25 May 2007, Pavel Machek wrote: > > > > Why the HELL cannot you realize that kernel threads are different? > > Ugh? We are talking about request_firmware() here, right? That's > calling userland helper to load the firmware...? Looks like USER > thread to me. Right. And if we had had the nice old /sbin/hotplug thing, it would all have worked fine - because it would just have done an execve(), and things would be happy. But people screwed that up too, and now udevd is an undebuggable user thread. Shit happens. See my other email about why even user threads can probably not be frozen, and the whole freezer thing is misdesigned. And I repeat: PowerPC had working and stable suspend five _years_ ago, without any of that freezing crud. We should rip it out. Linus
From: Pavel Machek [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Fri, 25 May 2007 01:18:52 +0200 Hi! > > > Why the HELL cannot you realize that kernel threads are different? > > > > Ugh? We are talking about request_firmware() here, right? That's > > calling userland helper to load the firmware...? Looks like USER > > thread to me. > > Right. And if we had had the nice old /sbin/hotplug thing, it would all > have worked fine - because it would just have done an execve(), and things > would be happy. > > But people screwed that up too, and now udevd is an undebuggable user > thread. Shit happens. See my other email about why even user threads can > probably not be frozen, and the whole freezer thing is misdesigned. I'm not ready to redesign udevd :-(. Your other mail proves that either 1) we can stop freezing udevd, and pray udevd does not become confused by "half hardware not available" while system is being suspended _or_ 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO PEOPLE FOR FIVE YEARS NOW. > And I repeat: PowerPC had working and stable suspend five _years_ ago, > without any of that freezing crud. We should rip it out. Imageine we killed freezer. Also imagine Romano has IDE card his PCMCIA slot. Kaboom, we solved nothing. We'll either deadlock or do something very nasty to the filesystem on the IDE card ... because we'll have udevd running, but fs on IDE card not available. That does not work. "Not freezing udevd" only makes problems hard to trigger, see? Now... "should we rip freezer out of suspend" is a different story. It does not help _here_. We still need to load the firmware during _suspend_. [Can you ack this point and we can have nice flamewar about ripping out freezer?] But I'd actually like to get rid of freezer for suspend (I believe it is needed for hibernation) -- we'll need to do similar that for runtime suspending of devices, anyway. But "just rip it out" will cause some hard to debug breakage, we need to somehow audit the drivers, or ask driver writers to audit them or something. ... and yes, ripping freezer out _will_ make drivers more complex. Your video capture card will now have to deal with "ouch, I was already told to suspend, and now someone is calling my ioctls() ?!". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
From: Linus Torvalds [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 17:37:49 -0700 (PDT) On Fri, 25 May 2007, Pavel Machek wrote: > > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO > PEOPLE FOR FIVE YEARS NOW. And people aren't listening. Have you thought about _why_? The thing is, it should just work. Even without pre-loading. > Imageine we killed freezer. Also imagine Romano has IDE card his > PCMCIA slot. Kaboom, we solved nothing. Don't be silly. We solved it. The firmware has to be loadable from somewhere else, since otherwise his IDE card wouldn't have been accessible in the first place! So all your arguments are just bogus crap. Linus
From: Nigel Cunningham [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Fri, 25 May 2007 11:55:22 +1000 Hi Linus. On Thu, 2007-05-24 at 17:37 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Pavel Machek wrote: > > > > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO > > PEOPLE FOR FIVE YEARS NOW. > > And people aren't listening. Have you thought about _why_? > > The thing is, it should just work. Even without pre-loading. > > > Imageine we killed freezer. Also imagine Romano has IDE card his > > PCMCIA slot. Kaboom, we solved nothing. > > Don't be silly. We solved it. The firmware has to be loadable from > somewhere else, since otherwise his IDE card wouldn't have been accessible > in the first place! > > So all your arguments are just bogus crap. Let me see if I can help. I'll probably fail miserably, but I can only try :) First, let me agree with you that for the atomic copy itself, the freezer is unnecessary. Disabling irqs and so on is enough to ensure the atomic copy is atomic. I don't think any of us are arguing with you there. Where we see the problem is with what happens after the atomic copy is made. The problem is that the atomic copy includes struct inodes, dnodes and such like - an in memory representation of the state of mounted filesystems. Imagine that, post atomic copy, we don't have the freezer. Processes can then make on-disk changes to these mounted filesystems in the time before we complete saving the image and powering down. If, at resume time, we then restore the atomic copy, we have a mismatch between what the in-memory data structures say and what the on-disk data says. This leads to corruption. How to avoid? Well, there are only two options as far as I can see. We either stop those changes occurring in the first place, or we make them undoable. Freezing processes, and/or filesystems would be the first path, checkpointing the second. So, as far as I can see, we're stuck with freezing processes at least until checkpointing is implemented. I have to admit though, that even if checkpointing was implemented, I'd like to see freezing processes remain. The image gets written faster if we don't have to compete for cpu and i/o. It also allows us to do a fuller image of memory than is otherwise possible (Yes, I know some people don't care for full images, but others of us have usage patterns that make the system far more useable if a full image is kept, or simply prefer to have our machines as if the power had never gone away). Without processes freezing, I'd have to work a lot harder to find a way to do that full image. The simplest way would probably be to carry the freezer code myself. (Yeah, I'm reconciled to the idea of never getting Suspend2 merged. I'd like it to happen, but won't hold my breath. Someone needs to break your suspend-to-ram or battery so you see the use for hibernation :>). Hope this helps. Nigel
From: Linus Torvalds [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 19:10:08 -0700 (PDT) On Fri, 25 May 2007, Nigel Cunningham wrote: > > First, let me agree with you that for the atomic copy itself, the > freezer is unnecessary. Disabling irqs and so on is enough to ensure the > atomic copy is atomic. I don't think any of us are arguing with you > there. First off, realize that the problem actually happens during suspend-to-ram. Think about that for a second. In fact, think about it for a _loong_ time. Because dammit, people seem to have a really hard time even realizing this. There is no "atomic copy". There is no "checkpointing". There is no "spoon". > Hope this helps. Hope _the_above_ helps. Why is it so hard for people to accept that suspend-to-ram shouldn't break because of some IDIOTIC issues with disk snapshots? And why do you people _always_ keep mixing the two up? Linus
From: Nigel Cunningham [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Fri, 25 May 2007 12:20:05 +1000 Hi Linus. On Thu, 2007-05-24 at 19:10 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Nigel Cunningham wrote: > > > > First, let me agree with you that for the atomic copy itself, the > > freezer is unnecessary. Disabling irqs and so on is enough to ensure the > > atomic copy is atomic. I don't think any of us are arguing with you > > there. > > First off, realize that the problem actually happens during > suspend-to-ram. > > Think about that for a second. > > In fact, think about it for a _loong_ time. Because dammit, people seem to > have a really hard time even realizing this. > > There is no "atomic copy". > > There is no "checkpointing". > > There is no "spoon". > > > Hope this helps. > > Hope _the_above_ helps. Why is it so hard for people to accept that > suspend-to-ram shouldn't break because of some IDIOTIC issues with disk > snapshots? > > And why do you people _always_ keep mixing the two up? It does. Sorry. I didn't read enough of the context. To answer the question, I guess the answer is that although they're different creatures, they have similarities. This is one of them, which is why I could make the mistake I did. Nothing in the issue being discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus too much on the similarities, but that doesn't mean they're not there. Regards, Nigel
From: Linus Torvalds [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 19:41:37 -0700 (PDT) On Fri, 25 May 2007, Nigel Cunningham wrote: > > To answer the question, I guess the answer is that although they're > different creatures, they have similarities. This is one of them, which > is why I could make the mistake I did. Nothing in the issue being > discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus > too much on the similarities, but that doesn't mean they're not there. I agree that the current bug is not unique to STR. In fact, I think Romano tested both STD and STR, and both had the same bug with the 60s timeout. But what irritates me is that STR really shouldn't have _had_ that bug at all. The only reason STR had the same bug as STD was exactly the fact that the two features are too closely inter-twined in the kernel. That irritates me hugely. We had a bug we should never had had! We had a bug because people are sharing code that shouldn't be shared! We had a bug because of code that makes no sense in the first place! I agree that disk snapshotting is much harder. If we had a bug just in that part, I wouldn't mind it so much. Getting hard problems wrong isn't something you should be ashamed of. What I mind is that the _easier_ problem got infected by all the bugs from the _harder_ issue. That just makes me really really angry and frustrated. Look at it this way: if you designed a CPU, and you made the integer code-path share everything with the floating point side, because "addition is addition", and as a result the latency for the simple arithmetic and logical ops in integer ALU was four cycles, what would you be? You'd be a moron, that's what. And that is _exactly_ what the current STD/STR code does. It says "suspend is suspend" and tries to share the same pipeline, even though the two operations are totally different, and share nothing but the name people use for it (and even the name is really pretty weak, and I've tried to get people to use some other name for STD). So yes,the two things _do_ share the problem, but they really really shouldn't. There's no reason to think that they should. And it drives me absolutely bonkers that people seem to have such a hard time seeing that. That said, I think freezing is crap even for snapshotting/suspend-to-disk, but the point of the above rant is to show how insane it is to think that problems and complexity in one area should translate into problems and complexity in another area. And if the snapshot people want to screw up their snapshots with freezing, I don't actually care that much. I'd much rather have working STR. As it is now, they're now _both_ broken. Linus
From: Nigel Cunningham [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Fri, 25 May 2007 13:00:40 +1000 Hi. On Thu, 2007-05-24 at 19:41 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Nigel Cunningham wrote: > > > > To answer the question, I guess the answer is that although they're > > different creatures, they have similarities. This is one of them, which > > is why I could make the mistake I did. Nothing in the issue being > > discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus > > too much on the similarities, but that doesn't mean they're not there. > > I agree that the current bug is not unique to STR. In fact, I think Romano > tested both STD and STR, and both had the same bug with the 60s timeout. > > But what irritates me is that STR really shouldn't have _had_ that bug at > all. The only reason STR had the same bug as STD was exactly the fact that > the two features are too closely inter-twined in the kernel. > > That irritates me hugely. We had a bug we should never had had! We had a > bug because people are sharing code that shouldn't be shared! We had a bug > because of code that makes no sense in the first place! > > I agree that disk snapshotting is much harder. If we had a bug just in > that part, I wouldn't mind it so much. Getting hard problems wrong isn't > something you should be ashamed of. What I mind is that the _easier_ > problem got infected by all the bugs from the _harder_ issue. That just > makes me really really angry and frustrated. > > Look at it this way: if you designed a CPU, and you made the integer > code-path share everything with the floating point side, because "addition > is addition", and as a result the latency for the simple arithmetic and > logical ops in integer ALU was four cycles, what would you be? > > You'd be a moron, that's what. > > And that is _exactly_ what the current STD/STR code does. It says "suspend > is suspend" and tries to share the same pipeline, even though the two > operations are totally different, and share nothing but the name people > use for it (and even the name is really pretty weak, and I've tried to > get people to use some other name for STD). I think I get what you're trying to say, but I also think you're either overstating your case ("...totally different and share nothing but the name...") or underestimating the similiarity - they both need (albeit for different reasons) to do the cpu hotplugging, driver suspending (yeah, there are similarities and differences there) and irq disabling. That's _some_ similarity. Apart from that, yeah - they are totally different. Re the name, we discussed changing the name of Suspend2 on IRC a night or two ago. We came to the conclusion that, for better or for worse, it's too well known now. I can see your logic in wanting to differentiate them, but I seem to be a bit stuck :\. Push some more. Maybe we'll get there anyway :) Maybe you can get rid of that horrible, unpronounceable 'swsusp' name while you're at it? :) > So yes,the two things _do_ share the problem, but they really really > shouldn't. There's no reason to think that they should. And it drives me > absolutely bonkers that people seem to have such a hard time seeing that. > > That said, I think freezing is crap even for snapshotting/suspend-to-disk, > but the point of the above rant is to show how insane it is to think that > problems and complexity in one area should translate into problems and > complexity in another area. Does that imply that you'd prefer to see filesystem checkpointing code, that you think freezing can be done better, or do you have some other solution that hasn't occurred to me? > And if the snapshot people want to screw up their snapshots with freezing, > I don't actually care that much. I'd much rather have working STR. As it > is now, they're now _both_ broken. Fair enough :). Nigel
From: Linus Torvalds [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 20:31:49 -0700 (PDT) On Fri, 25 May 2007, Nigel Cunningham wrote: > > > > That said, I think freezing is crap even for snapshotting/suspend-to-disk, > > but the point of the above rant is to show how insane it is to think that > > problems and complexity in one area should translate into problems and > > complexity in another area. > > Does that imply that you'd prefer to see filesystem checkpointing code, > that you think freezing can be done better, or do you have some other > solution that hasn't occurred to me? I actually don't think that processes should be frozen really at all. I agree that filesystems have to be frozen (and I think that checkpointing of the filesystem or block device is "too clever"), but I just don't think that has anything to do with freezing processes. So I'd actually much prefer to freeze at the VFS (and socket layers, etc), and make sure that anybody who tries to write or do something else that we cannot do until resuming, will just be blocked (or perhaps just buffered)! See? I actually think that this process-based thing is barking up the wrong tree. After all, it's really not the case that we need to stop processes, and stopping processes really does have some problems. It's simpler in some ways, but I think a more directed solution would actually be better. >bviously we _do_ want to actually try to quiesce normal user processes. >But by "normal user", I'd be willing to limit it to non-uid-zero things, >for example. Exactly because it does turn out that the kernel kind of >depends on user-land things for stuff like network filesystem connection >setup etc (ie we tend to do things like the mount encryption stuff in >userland!). But I really don't care that deeply per se, exactly because I don't use it myself. I think people are going down the wrong rabbit-hole, but it wouldn't _irritate_ me that much except for the fact that it now also impacts suspend-to-RAM. Linus
From: Nigel Cunningham [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Fri, 25 May 2007 14:33:07 +1000 Howdy. On Thu, 2007-05-24 at 20:31 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Nigel Cunningham wrote: > > > > > > That said, I think freezing is crap even for snapshotting/suspend-to-disk, > > > but the point of the above rant is to show how insane it is to think that > > > problems and complexity in one area should translate into problems and > > > complexity in another area. > > > > Does that imply that you'd prefer to see filesystem checkpointing code, > > that you think freezing can be done better, or do you have some other > > solution that hasn't occurred to me? > > I actually don't think that processes should be frozen really at all. > > I agree that filesystems have to be frozen (and I think that checkpointing > of the filesystem or block device is "too clever"), but I just don't think > that has anything to do with freezing processes. > > So I'd actually much prefer to freeze at the VFS (and socket layers, etc), > and make sure that anybody who tries to write or do something else that we > cannot do until resuming, will just be blocked (or perhaps just buffered)! > > See? I actually think that this process-based thing is barking up the > wrong tree. After all, it's really not the case that we need to stop > processes, and stopping processes really does have some problems. It's > simpler in some ways, but I think a more directed solution would actually > be better. That does sound doable. I'm sorry to say it, but dropping process freezing still seems to me like the better way though. I prefer it because of the reliability aspect. With the current code, having frozen processes, I can look at the state of memory, calculate how much I'll need for this or that and know that I'll have sufficient memory for the atomic copy and for doing the I/O (making assumptions about how much memory drivers will allocate) before I start to do either. If we stop freezing processes, that predictability will go away. There'll always be a possibility that some process will get memory hungry and stop me from being able to get the image on disk, and I'll have to either abort or give up and try again and again until I can complete writing the image, the battery runs out or whatever... > >bviously we _do_ want to actually try to quiesce normal user processes. > >But by "normal user", I'd be willing to limit it to non-uid-zero things, > >for example. Exactly because it does turn out that the kernel kind of > >depends on user-land things for stuff like network filesystem connection > >setup etc (ie we tend to do things like the mount encryption stuff in > >userland!). Not sure who you're quoting here, but it's not me. Pavel maybe? I was unsub'd for a couple of weeks, so guess it's from during that period. > But I really don't care that deeply per se, exactly because I don't use it > myself. I think people are going down the wrong rabbit-hole, but it > wouldn't _irritate_ me that much except for the fact that it now also > impacts suspend-to-RAM. Does that mean you never ever power off your laptop (assuming you have one), and the battery never runs out? Surely you must power it off completely sometimes? If you do, doesn't that ever happen at a time when you're part way through something and you'd like to be able to pick up your merge or whatever later without having to say "Now, where was I up to?" *shrug* Maybe you're just exceptional :) (Yeah, we know you are in other ways, but this way?...) Regards, Nigel
From: Linus Torvalds [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Thu, 24 May 2007 21:49:58 -0700 (PDT) On Fri, 25 May 2007, Nigel Cunningham wrote: > > Does that mean you never ever power off your laptop (assuming you have > one), and the battery never runs out? Surely you must power it off > completely sometimes? So? The bootup isn't that much worse than a disk suspend/resume, and it's reliable. And actually, I don't use laptops much. I use mostly desktops, and STR works fine on at least some of them. In contrast, doing some suspend-to-disk thing would just be insane and idiotic. If I have to wait for half a minute and have a slow system even after that because my git trees aren't in the cache, I really might as well just shut them off. In contrast, STR means they are quiet and don't waste energy when I don't use them, but they're instantly available when I care. HUGE difference. I really think suspend-to-disk is just a total waste of my time. Linus
From: Nigel Cunningham [email blocked] Subject: Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review Date: Fri, 25 May 2007 15:18:46 +1000 Hi. On Thu, 2007-05-24 at 21:49 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Nigel Cunningham wrote: > > > > Does that mean you never ever power off your laptop (assuming you have > > one), and the battery never runs out? Surely you must power it off > > completely sometimes? > > So? The bootup isn't that much worse than a disk suspend/resume, and it's > reliable. > > And actually, I don't use laptops much. I use mostly desktops, and STR > works fine on at least some of them. In contrast, doing some > suspend-to-disk thing would just be insane and idiotic. If I have to wait > for half a minute and have a slow system even after that because my git > trees aren't in the cache, I really might as well just shut them off. > > In contrast, STR means they are quiet and don't waste energy when I don't > use them, but they're instantly available when I care. HUGE difference. > > I really think suspend-to-disk is just a total waste of my time. Ah. That's because you're using [u]swsusp. If you used Suspend2, your git trees would be in the cache, your system wouldn't be slow and you'd still be back up in that half a minute or so - probably less time. Give it a try for a week, and then go back to rebooting. After that, tell me rebooting is better and I've wasted the last 5 or 6 years improving the code. Regards, Nigel
Good last mail, Nigel. Let's
Good last mail, Nigel. Let's see :D
Seriously.
As entertaining as he is, Linus can really be an asshole sometimes.
Sometimes? Did you see his
Sometimes? Did you see his recent talk at Google? Quite rude if you ask me.
Yeah
Yeah, I don't mind his little outbursts, but the google talk really hurt a lot of people in the audience (google hired a lot of subversion people.)
Now, Linus claimed svn was the most pointless project ever, because improving CVS is impossible/stupid/whatever.
But the fact is, CVS is used a lot (sometimes for political reasons, but that doesn't matter - programmers are stuck with it) and it has a bad design and SVN *does* improve on it. SVN doesn't match the linux dev model at all, but SVN acknowledge that fact. A lot of people who are stuck in the CSV is world is now stuck in the SVN world, and it's a slightly better place. See Linus? You're the moron.
Linus was an idiot and he should say "sorry" (although there is no chance in hell that will happen)
There are two parts in an
There are two parts in an insult: Offensive words and taking offence. If hurt feelings occured due to Linus' presentation, I blame cultural differences. Because although he used offensive qualifications, he did explain his opinions. People who disagree with his reasoning should simply discard the bad words, and even could call him an idiot instead.
"he did explain his
"he did explain his opinions"
So having a different opinion qualifies for calling people idiots?
I didn't think it was funny. It was just really lame.
I didn't find it offending.
I didn't find it offending. He was just trying to be funny. How can anyone take it seriously?
It wasn't funny, hence ppl
It wasn't funny, hence ppl take it seriously.
Stop whining over a f*cking
Stop whining over a f*cking flame...
Linus isn't interested in "political reasons"
Linus isn't interested in "political reasons" or being "stuck with it" - he doesn't put up with crap like that. He wants the best software because he doesn't waste time with junk. And SVN & CVS are junk.
So he designed and wrote something that worked and did what he needed it to do.
Programmers are NOT stuck with it, you can always write something better, it's why you're a programmer. If you're "stuck with it" because of your job, well then your job (and mine) sucks because of that. I use that chunk of sh*t every day, I know it sucks. But hey, they pay me a lot of money to sit there and watch it crap out, so I don't really care.
Linus doesn't need to say he's sorry, he backed up his mouth with action and wrote GIT. I fail to see anyone else doing that... instead they moan about how they're "stuck" with SVN/CVS.
And if that hurts the subversion people's feelings, then they shouldn't write such crap. Step up and write something useful with a decent design. Don't whine about hurt feelings.
That's like saying we don't need to have Linux because we have Windows and "people are stuck with it"
SVN vs. git
I agree that a lot of people got annoyed by the presentation Linus chose to attack a version control model that is not designed to be distributed and therefore not useful for large scale community projects. They are missing the whole point. It was not a speech on how bad SVN is. It was a speech on the need for developers to focus on the design of distributed SCM systems. He has done his part on that issue.
"I'm a bastard. I have
"I'm a bastard. I have absolutely no clue why people can ever think otherwise. Yet they do. People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work, if it just results in what I consider to be a better system."
- Torvalds
I loved his talk at Google.
I loved his talk at Google. It's what makes him as good as he is.
He slams Linux as readily as he slams anything else. The alternative is to a "manager" and we don't that.
Have a Ytoob/Goodeo link?
Have a Ytoob/Goodeo link?
Youtube Linus Google talk link...
Ytoob link might be this: Tech Talk: Linus Torvalds on git (there are comments criticising his "disrespect" of SVN and Perforce so perhaps this is the right one...)
Linux and STR
I completely agree with Linus: Linux is really too much late compared to windows for STR. I also aggree than STD is not really useful... Because it just takes you as long as a clean shutdown so it's really near from being useless!
I think this prevents many laptop users from coming to Linux... On such a growing market, this must not be considered as good news.
For both desktops and laptops, when energy saving becomes a growing issue in the world... I think the risk to see tux images showing our penguin as a dissolving agent of it's own ice-barrier should really be considered: It could be on current microsoft agressive communication plan.
Regards
Suspend to disk useless?
Suspend to disk useless? Bollocks. It may take a while to shut down, but it's still much faster to resume than a regular boot.
And for laptops without a lot of battery life, the "no power use at all while shut down" aspect of it is critical
I was thinking... in comparaison to STR...
Because in this case (STR), resume is done in 1 or 2 sec, and a laptop can stay in STR state for many hours... always more than half a day... one day if battery was at least 50% charged when suspend is done on most laptop hardware.
And if I need to suspend my work for more time? That's not so often and I really prefer a clean shutdown, closing all my files without any data loss risk because I have never found STD fully reliable under linux.
So my opinion is: If you have a good STR, you no more use STD!
Regards.
STR is useless in many cases
The point is: on STR you need power, on STD you don't. So if you have a power outage and your UPS buys you just enough time to suspend your servers/workstations, what good is STR? Likewise for Laptops, the always accurate battery readout jumps from 30% to 5% and your sitting in a train with no chance of charging up for the next two hours, what good is STR?
well i guess it can be MRAM
well i guess it can be MRAM ;)
STD? Who needs that when you can shutdown?
You still have enough time to save and exit cleanly in both situations.
If not, then you've got a problem even hibernation won't save you from - it requires saving a large chunk of mem to HDD.
The only problem is that automatic shutdown can't be easily automated w/o coordination of a large part of userland.
X session support, anyone? Not implemented almost everywhere. Though with the latest DBus hype it might soon be possible to implement lightly. Just broadcast a shutdown message and all apps start writing their data to a special location, then close gracefully.
The X session protocol or a helper app would then restart them. Hopefully they'll get the arguments from the previous session or notice letfover temporary files.
When the userland can interact, just let it. The batch tasks aren't a problem, and anyone writing these in a way that interruption will not allow another try to run is a real moron.
(e.g. waiting on pidfiles is one such problem - though this one could be resolved by init scripts)
System startup time is already below 10-15 seconds here and shutdown is even faster.
Hibernation just can't be faster. What I can't wait for is a real fscache reedition - so one can save the filesystem cache for quicker bootup and startup of apps.
Am I the only one who finds use for both?
STR is good for saving power for short periods. If I'm not going to be using my laptop for 15 minutes, I'd like to be able to put it in S3.
(In reality, I can't use STR on my laptop. There's a weird bug (that doesn't happen on you-know-who's OS) where the system will enter S3 normally, but attempting to wake it up will cause a normal boot instead. This bug was my best lead (I have an Averatec system like a couple of the posters there), but it doesn't actually fix the problem. I keep chickening out when it comes to either asking this bug to be reopened or filing a new one.)
STD is great for saving the state of work without having to close applications. I can keep open my 20 Firefox tabs without having to abnormally close the program. I can remember exactly what else I was doing.
Second swap + LZO.
Please, create a second swap partition (a little bit bigger)
and use LZO real-time compression for STD.
STD/R and Notebook usage
One thing people need to realize is that suspend to ram is not free on notebooks and uses battery power.
Continually taking a few percentage points off a notebook battery when it would not otherwise be used at all is a very bad usage pattern for most LIon batteries as the battery controller will top them off more often reducing their useable lifetime.
There are a *lot* of people who do the following every day:
*power off* notebook in morning
drive to work
*power on* notebook at work
*power off* notebook at end of work day
drive home
*power on* notebook when home.
Who cares about the boot time of the kernel/OS. Its the boot time of the underlying applications that matter the most. If I have hundreds of applications running working a specific problem I don't want to have to waste my time starting them all again when I move from one location to another. Suspend/resume to disk is quick enough for me and regular use of suspend to ram unecessarily chisels away at useable battery life and is less reliable (In mostly human terms of forgetting to plug in a suspended notebook) The above applies especially to notebooks with lots of memory.
In STR... the processor will
In STR... the processor will shut down all its execution units, lower its frequency... and only monitor a few interrupts events (keyboard and/or power button). All bus activity will be stopped, DDR will be set in auto-refresh mode by memory controller before almost stopping the CPU.
Power consumption is almost nothing... and a battery also discharge when not in use at all.
Used in conjonction with power saving policies, a lot of power usage (and component heating, which could cost much more than a battery every 2 years) is saved every time you leave your computer for a coffee.
When I go back home... as I told you, I prefer a clean shutdown, even if I have to open again my applications. And when you work much of your time on a network, STD is also not so useful there again: All your connections will have go down so when you come back you'll have to re-open almost everything
I'm speaking from
I'm speaking from experience. I went through two batteries that I never really used otherwise doing the above its not an effect that I just made up.
Until I started suspending to disk the battery controller would top of the battery every day. Now its more on the order of once every two weeks.
With > 2gigs of ram suspended for an hour or two a very noticable chunk of battery life is gone.
the memory effect in nickel-metal-hydride
What you are talking about is called "the memory effect" in batteries, and it was a big problem with the old generation of nickel-metal-hydride batteries. With nickel-metal-hydride, the ideal thing to do was to discharge the battery COMPLETELY, then recharge fully. If you recharged the battery before it was completely recharged, you would permanently lose part of the battery capacity.
With the new lithium-ion batteries, the situation is completely reversed. The best thing to do for lithium-ion is to recharge it as often as possible. Discharging a lithium-ion battery completely causes you to, you guessed it, permanently lose part of the battery capacity.
Of course the consumer electronics manufacturers have done little to educate people about this 180 degree turn in battery technology. Why should they-- when people have to buy new gear, it's all gravy to them.
This is a very complicated
This is a very complicated space that changes regularly and its not as cut and dry...
The gas gauge used to determine when a LIon battery is charged *does* suffer from memory effects.
Thats partially why you need to deep cycle your batteries every month or so to recover capacity.
LIon batteries have no tolerance for overcharging of any kind. There is a lot of voodoo going on with batteries. The chemistry in manufacturing is constantly changing on the order of two to three times per year and the properties may change subtly as a result.
I happen to have a thinkpad and their "autonomic" battery manager explicitly sets water marks to prevent constant recharging for the express purpose of preserving the longevity of their batteries.
Keeping cells fully active if their not going to be used for a while is not the best thing for them and as you say neither is allowing them to fully discharge. There is an optimal middle ground "somewhere".
The gas gauge used to
The gas gauge used to determine when a LIon battery is charged *does* suffer from memory effects. Thats partially why you need to deep cycle your batteries every month or so to recover capacity.
I actually didn't know that, but I looked it up, and you're right.
I looked on this website, and it confirms it: http://www.batteryuniversity.com/parttwo-34.htm
It also seems that you should "avoid frequent full discharges because this puts additional strain on the battery." So, you can have a long-lived battery, or a working percent gauge. Thanks guys!
And they say that software is unreliable.
Gauges are better now
The percent gauge should be ok for the whole lifetime of the battery if calibrated _once_, in normal conditions (not too high humidity, 15-25 °C). These things are now much better than some years ago.
The max capacity parameters and the zero point are stored in non-volatile memory. (accessible partially through ACPI, too) They may be slightly different over the lifetime of the battery - but they are actually much more dependent on the surrounding temperature than wear.
Short story: you have to cycle the battery once for the gauge to calibrate, then avoid the process. Also, always store the battery charged when unused.
If you notice the gauge being really incorrect, cycle the battery once more.
But it shouldn't be required.
check if something doesn't go to sleep properly
My T42 with 1 GB can sleep for more than a week with a full battery (250 mW drain).
But this doesn't work out of the box (more like 650 mW then). It needs quite a bit of tinkering; e.g. certain drivers need to be compiled as modules and unloaded. Did take me a while to get it this way, starting with a new Debian install.
You might want to calculate battery drain during sleep and see if something goes wrong.
BTW, the optimum charge for storage of Li-Ion batteries is said to be 40%.
Linus misses the point
Linus misses a key point -- other people are not like him. He's a low level developer so chances are, his typical desktop has 1 to 4 command lines open, a web browser, and an email client. It should be extremely for him to restore his working state within seconds of logging in. And if the power goes off and while things are suspended to RAM, no big deal.
If, OTOH, you have multiple projects, and long documents, open to specific subsections, then restoring your system to precisely the same state is nontrivial. And if either you're almost out of power or you can't guarantee that you'll be back in time before the suspend to RAM dies due to power shortage, suspend to RAM is useless.
Both types of suspend have their uses.
In my understanding, Linus
In my understanding, Linus main concern is not to remove STD... but to have a working STR that should not share so much STD code because it's not really the same problem (and as a low level developper, he perfectly knows that): STD is closer to a normal shutdown than STR, which deals more with using power saving technologies now built in most hardware.
Another concern is what is more useful? STD when you have to freeze work for many hours: Not so often for most people... or STR, maybe 20 times a day, to replace the screen saver and save power + preserve the hardware from heating doing nothing?
It's right to say than focus on STD is not in phase with users needs... and that STR should be up-prioritized.
He's really in his role of linux project leader by saying this. Which was maybe not conçerning the gnome/kde debate (in my mind: Users can choose and I can install gnome for my old mother and KDE for myself, even if from his point of view it can be seen as a ressource waste). He have identified a big lack and reacts giving a development direction and that's his job. On top of that, linux is years after windows for suspends...
STD is in phase with users'
STD is in phase with users' needs, just not Linus' needs. It's a bit of an arrogant position, but it's his kernel. Just because Linus does not have frequent power outages, use a laptop, or boot several operating systems and thus doesn't need STD does not mean that users do not need STD.
It is true that it would be better to have 100% working STR and <100% working STD that don't share code, than <100% working STR/STD that share code. What is up for question is if the code sharing is really the problem.
I really do think that code
I really do think that code sharing is a problem because one issue is more related to a shutdown that just preserve running programs state (and thus this is not really a kernel business)... and the other with using hardware build power management possibilities.
But you're right that in some under developped countries (but lot of low-cost externalized software!) power outages several times a week (a day?) can be an issue... and STD useful... if you have an alternative supply to have time to do so... that would also give you some time to remain in STR!
But is this really linux job to try cope with outdated infrastructures? On my side, power outage is 1 or 2 times a year and almost never more than a few minutes... Not an issue in a developped country.
The industries leaving there will have a service for their money, they should know this and this does not trouble my sleep... and infrastructures is not the only problem that will affect their productivity: The choice to make a few years 2 digits benefits have some counterparts that are far from OS kernel deals.
Regards
As a laptop-user i fully
As a laptop-user i fully agree that STD is an very important feature. Think on "Power outage" as "I did a lot of work, have many opened projects, my battery is very low and there is no socket out there". Well, and sometimes i just forget to connect my laptop to my power supply. The device stands on the table, i'm in another room and come back a hour later. It happened more than one time that an automatic STD at low battery state (5%) saved my work.
Btw, i live in germany. I can't remember of more than two "global" power outage in the last year. But we had *many* power outages in our house, just because it's local infrastructure is very old. When someone is about to start the vacuum cleaner he reminds everybody to save their applications. STD is a very nice feature in such situation, if you want to avoid to launch everything again.
The big point people are
The big point people are missing, IMHO, is this could be fully solved in user-space. What happens now, for example, when the X server exits a notification is sent to programs to shutdown, the kill signal. So all that needs to be done is that X applications save their state and on automatic startup (KDE saved their scheme) restore their state as good as they can. This is a bit like init scripts start up & stop servers that keep a cache of information on-disk
IMHO this is the only way suspend-to-disk should be implemented, that is: totally in user-space and voluntary for programs. So Linus is right, as always, this is a waste of his time... ;-)
I have to wonder.
Is it worth doing all this userspace freezer stuff, even for hibernation, when the gain is merely "move stuff out of the kernel"? Far as I understand, uswsusp stops hardware and userspace, then takes an "atomic copy" (where? does it drop caches to make room? how can it be sure that's sufficient?) of all memory in the system, and then dumps it through a helper program in a sort of a "phantom continuation" of a userspace which vanishes for good once the helper program has finished.
Yet that userspace helper program can mess around with filesystems (unless strictly restricted to block device access?) and so forth, causing the system to "jump back in time" on resume for about as much time as it took for the uswsusp userspace helper to do its thing when the system was hibernated. Boom, filesystem state shear -> corruption. I really hope I'm wrong on this point.
It just seems that having uswsusp in the kernel rather than the redheaded stepchild known as suspend2 seems the totally wrong status for things. Suspend2 is already mature, and as stable as you can get, whereas uswsusp is absurdly experimental for something that's in an even-minor kernel.
Compared to suspend2, uswsusp is like the square peg in a round hole. If you're trying to transparently suspend userspace for an arbitrary period of time, where the most that ordinary programs would notice is some clock warping, how on earth are you going to accomplish this without completely and rather permanently shutting down said userspace? Hibernation is a naturally in-kernel task, isn't it? Why pretend it's any better moving bits of it into a phantom userspace? Flexibility? No, don't give me any of that. Kernel modules were invented to get flexibility in kernel-space features. Only this relatively recent pogrom against unloadable kernel modules has made them a second or third preference.
So how the hell come suspend2 is still outside the kernel? Has mr. Torvalds gone all RMS, making snap judgements that are henceforth carved in immutable stone?