The Linux Kernel version 2.6.25 introduces a new Linux process sleeping state, TASK_KILLABLE: If a process is sleeping killably in this new state, it works like TASK_UNINTERRUPTIBLE with the bonus that it can respond to fatal signals. This feature is generally an improvement over the existing options -- after all, it is another way to keep from getting stuck with dead processes.
Post a Comment
Member since:
2005-07-06
Member since:2005-07-06
Member since:2005-07-24
What? I'd say "Hurray!!!" I've been waiting for this feature for 20 years. Basically, no more reboots to get rid of stuck processes that kill -9 can't zap.
The IBM article is perhaps a bit dry, though. Jonathan Corbet is more engaging:
http://lwn.net/Articles/288056/
Edited 2008-10-02 18:26 UTC
Member since:2005-07-06
Member since:
2006-09-22
Member since:2005-12-31
> Seems like that would have been a better approach for Linux.
preap removes zombie processes, i.e. processes that have exited but whose exit status has not been collected yet. The article isn't about zombie processes though, but rather about processes that sleep indefinitely and uninterruptably in kernel mode.
Member since:2005-07-24
Member since:
2006-01-16
I want to give a little clarification about what's going on here.
What's going on here does not affect user-space at all.
The scenario is as follows: The program in user-space asks for some operation in kernel-space, mostly this would be some I/O. Then something gets stuck in kernel-space, e.g. caused by nasty behaviour of a device driver. The program stays in an _inconsistent_ state forever, and nobody is allowed to clean it up.
User-space never gains any knowledge about this. Even in the new KILLABLE state, user-space would never receive the KILL signal, the program would just be terminated instead of finishing the operation which made it stuck.
The question now is: Why couldn't KILLABLE just replace UNINTERRUPTABLE? The idea behind this is, that some operations, if not properly finished or aborted, leave the _kernel_ in an inconsistent state. That means for example, a lock could have been set and would need to be removed.
For KILLABLE to work, specific parts of the kernel, which set the process into the UNINTERRUPTABLE state before, need to be rewritten to use this new state and make sure it works properly.
What I don't understand, though:
- with current UNINTERRUPTABLE, the inconsistent state problem is still there, and will never be resolved, anyway. So how does it help not to at least clean as much as possible?
- what happened with INTERRUPTABLE sleeping processes? The inconsistent state would also not be resolved just by the process catching signals and dealing with them in user-space, would it?
Edited 2008-10-02 21:03 UTC
Member since:
2005-11-12
I'm guessing that sleeping processes consume memory but not cpu cycles. I'm looking forward to kernel changes coming with the Ubuntu Intrepid Ibex release to recognize CPU scaling with Atom processors. I saw a comment on the eee-Ubuntu maintainer's blog suggesting that low power modes would be utilized more with the next Ubuntu release. It is kind of interesting since I get about 6 hours running Open Office all day on XP and about 5 hours running Ubuntu Hardy. I'm guessing that Asus has kernel modules for XP that leverage the Atom CPU's low power modes.
Member since:2006-01-02
Member since:2006-01-02
Your comment has nothing to do with the article except for the first sentence.
On a desktop system, 99% process time is spent in some sort of sleep state (almost always TASK_INTERRUPTABLE) as the processes are waiting on I/O or some event to occur. So yes, they do consume memory but no CPU cycles while sleeping.
Member since:
2008-08-25
