On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:That's not an advantage. That's why it has *sucked*. Trying to freeze kernel threads has _caused_ problems. It has _added_ these interdependencies. It hasn't removed a single dependency at any time, it has just added new problems! NONE of these are valid explanations at all. You're listing totally theoretical problems, and ignoring all the _real_ problems that trying to freeze kernel threads has _caused_. If you want to control user-mode helpers, you do that - you do not freeze kernel threads! And no, kernel threads do not submit IO to disks on their own. You just made that up. Yes, they can be involved in that whole disk submission thing, but in a good way - they can be required in order to make disk writing work! The problem that suspend has had is that it's done everything totally the wrong way around. Do kernel threads do disk IO? Sure, if asked to do so. For example, kernel threads can be involved in md etc, but that's a *good* thing. The way to shut them up is not to freeze the threads, but to freeze the *disk*. Linus -
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Andrew Morton | -mm merge plans for 2.6.23 |
| KAMEZAWA Hiroyuki | Re: 2.6.23-mm1 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
git: | |
| Alan Cox | Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
