wait queue process state
Hi,
I am quite new to this list and thus does not know if this question
has been answered many a times. I have looked in the archive but could not find it. Here goes anyway:
I realised that when processes are placed in the wait queue, they
are set at either INTERRUPTIBLE or NONINTERRUPTIBLE. I also noticed that something like file access is set as NONINTERRUPTIBLE. Could someone please tell me the reason for having these two states. I can understand that INTERRUPTIBLE can be made to be interrupted by a timer or a signal and vice versa for UNTERRUPTIBLE. Yet what makes blocking system calls as INTERRUPTIBLE or NONINTERRUPTIBLE. Also why is file access considered as NONINTERRUPTIBLE.
In addition, inside the kernel running, are these two different states treated differently (apart from the allowance to be interrupted or otherwise).
The reason I am asking is that I am working on scheduler activations which allow new kernel threads to be created when a kernel thread blocks inside the kernel. Yet this only works for INTERRUPTIBLE processes, I was thinking of making it work also for NONINTERRUPTIBLE processes. Just wondering if this would have any repurcusions. Also when a process generates a page fault which causes a page to be retreived from the filesystem, it such a process placed in the wait queue as NONINTERRUPTIBLE also ?
Cheers
Joseph Cordina
University of Malta
Quoted 8 lines · Joseph Cordina
The reason I am asking is that I am working on scheduler activations which allow new kernel threads to be created when a kernel thread blocks inside the kernel. Yet this only works for INTERRUPTIBLE processes, I was thinking of making it work also for NONINTERRUPTIBLE processes. Just wondering if this would have any repurcusions. Also when a process generates a page fault which causes a page to be retreived from the filesystem, it such a process placed in the wait queue as NONINTERRUPTIBLE also ?
filemap_nopage() from mm/filemap.c does wait_on_page() or some variant thereof (2.5 has wait_on_page_locked()) in several places, and it's placed into the TASK_UNINTERRUPTIBLE state while doing so.
Cheers,
Bill
Well, the only reason I'm aware of is that your have system calls that can't be interrupted, and sys calls that can (and when they do they return -1 and errno=EINTR).
The number of syscall that actually can return EINTR is actually fairly small. And some like read()/write() may or may not depending on the type of file. If the file is a socket it usually can, but if it's a regular file it can't.
A regular file access is as you uninteruptable as you point out, and to top it of it can be made nonblocking. The reason is that a regular file IO is deterministic, it must succeed or fail ASAP, and if it fail it's either a full FS, or a corrupt FS or a HW failure. (The latter two req reboot/HW repair, the first is a "normal" case). Socket IO is nondeterministic and we need a way to interrupt it.
I guess deterministic/nondeterministic activities is one way to describe either a kernel task is interruptable or nor. Another rule of thumb is that you're noninteruptable if you're waiting for HW to complete a task. (If you don't want to wait, you should have done it async anyway). You're interruptable if you wait for another program to do a task.
Make sense?
TJ
Quoted 36 lines · Joseph Cordina
Hi,
I am quite new to this list and thus does not know if this question
has been answered many a times. I have looked in the archive but could not find it. Here goes anyway:
I realised that when processes are placed in the wait queue, they
are set at either INTERRUPTIBLE or NONINTERRUPTIBLE. I also noticed that something like file access is set as NONINTERRUPTIBLE. Could someone please tell me the reason for having these two states. I can understand that INTERRUPTIBLE can be made to be interrupted by a timer or a signal and vice versa for UNTERRUPTIBLE. Yet what makes blocking system calls as INTERRUPTIBLE or NONINTERRUPTIBLE. Also why is file access considered as NONINTERRUPTIBLE.In addition, inside the kernel running, are these two different states treated differently (apart from the allowance to be interrupted or otherwise).
The reason I am asking is that I am working on scheduler activations which allow new kernel threads to be created when a kernel thread blocks inside the kernel. Yet this only works for INTERRUPTIBLE processes, I was thinking of making it work also for NONINTERRUPTIBLE processes. Just wondering if this would have any repurcusions. Also when a process generates a page fault which causes a page to be retreived from the filesystem, it such a process placed in the wait queue as NONINTERRUPTIBLE also ?
Cheers
Joseph Cordina
University of Malta-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 10 lines
_________________________________________________________________________ Terje Eggestad mailto:[email protected] Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________
Quoted 23 lines · Terje Eggestad
Well, the only reason I'm aware of is that your have system calls that can't be interrupted, and sys calls that can (and when they do they return -1 and errno=EINTR).
The number of syscall that actually can return EINTR is actually fairly small. And some like read()/write() may or may not depending on the type of file. If the file is a socket it usually can, but if it's a regular file it can't.
A regular file access is as you uninteruptable as you point out, and to top it of it can be made nonblocking. The reason is that a regular file IO is deterministic, it must succeed or fail ASAP, and if it fail it's either a full FS, or a corrupt FS or a HW failure. (The latter two req reboot/HW repair, the first is a "normal" case). Socket IO is nondeterministic and we need a way to interrupt it.
I guess deterministic/nondeterministic activities is one way to describe either a kernel task is interruptable or nor. Another rule of thumb is that you're noninteruptable if you're waiting for HW to complete a task. (If you don't want to wait, you should have done it async anyway). You're interruptable if you wait for another program to do a task.
Quoted 3 lines
Make sense?
TJ
I'm not going to speak to whether this is true in the current kernels or not.
The read system call is interuptable, period. Disk access
is considered slow. If you code asuming it will not be
interupted or that an interupt will cause a return of -1 your code may break on Linux and will certainly not be portable.
POSIX is ambigious on this and disk reads (on UNIX) have historically returned partial data when interupted during a disk read where some of the data was already in buffer.
Quoted 56 lines · Joseph Cordina
Quoted 36 lines
Hi,
I am quite new to this list and thus does not know if this question
has been answered many a times. I have looked in the archive but could not find it. Here goes anyway:
I realised that when processes are placed in the wait queue, they
are set at either INTERRUPTIBLE or NONINTERRUPTIBLE. I also noticed that something like file access is set as NONINTERRUPTIBLE. Could someone please tell me the reason for having these two states. I can understand that INTERRUPTIBLE can be made to be interrupted by a timer or a signal and vice versa for UNTERRUPTIBLE. Yet what makes blocking system calls as INTERRUPTIBLE or NONINTERRUPTIBLE. Also why is file access considered as NONINTERRUPTIBLE.In addition, inside the kernel running, are these two different states treated differently (apart from the allowance to be interrupted or otherwise).
The reason I am asking is that I am working on scheduler activations which allow new kernel threads to be created when a kernel thread blocks inside the kernel. Yet this only works for INTERRUPTIBLE processes, I was thinking of making it work also for NONINTERRUPTIBLE processes. Just wondering if this would have any repurcusions. Also when a process generates a page fault which causes a page to be retreived from the filesystem, it such a process placed in the wait queue as NONINTERRUPTIBLE also ?
Cheers
Joseph Cordina
University of Malta-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/Signature · 16 lines
_________________________________________________________________________ Terje Eggestad mailto:[email protected] Scali Scalable Linux Systems http://www.scali.com Olaf Helsets Vei 6 tel: +47 22 62 89 61 (OFFICE) P.O.Box 150, Oppsal +47 975 31 574 (MOBILE) N-0619 Oslo fax: +47 22 62 89 51 NORWAY _________________________________________________________________________ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Signature · 5 lines
________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: [email protected] Remember Cernan and Schmitt
Quoted 5 lines · jw schultz
The read system call is interuptable, period. Disk access
is considered slow. If you code asuming it will not be
interupted or that an interupt will cause a return of -1 your code may break on Linux and will certainly not be portable.
Linux does not permit interrupting regular file reads on local disks; only NFS supports it. Maybe 2.5 is the time to change this.
-ben
Quoted 9 lines · Benjamin LaHaise
Quoted 5 lines · jw schultz
The read system call is interuptable, period. Disk access
is considered slow. If you code asuming it will not be
interupted or that an interupt will cause a return of -1 your code may break on Linux and will certainly not be portable.Linux does not permit interrupting regular file reads on local disks; only NFS supports it. Maybe 2.5 is the time to change this.
What Unix and standards say and do make that one unfortunately a very bad idea. Its true that to the letter of the specs you can do interruptible disk I/O. Its also true to the real world that vast amounts of software breaks in subtle, unreported, oh hell what ate my file kind of ways
Quoted 5 lines · [email protected] said:
What Unix and standards say and do make that one unfortunately a very
bad idea. Its true that to the letter of the specs you can do interruptible disk I/O. Its also true to the real world that vast amounts of software breaks in subtle, unreported, oh hell what ate my file kind of ways
Broken software can be fixed.
There are few excuses for uninterruptible sleep. Most of them are 'I was too lazy to write the cleanup path.'
The one you offer seems to be 'Other people are too lazy to write the cleanup paths which POSIX mandates.' -- which isn't a great deal more acceptable than the original excuse, IMHO.
What I'd _really_ like at the moment is an option to allow read_inode() to be interruptible. Currently there's no way for it to exit without leaving a bad inode behind, which prevents the _next_ iget() for that inode from actually succeeding.
--
dwmw2
Quoted 1 line · David Woodhouse
Broken software can be fixed.
Given an infinite number of monkeys yes. The 'disk I/O is not interruptible' assumption is buried in vast amounts of software. This isnt a case of sorting out a few misbehaving applications, you can start with some of the most basic unix programs like 'ed' and work outwards.
Quoted 4 lines
There are few excuses for uninterruptible sleep. Most of them are 'I was too lazy to write the cleanup path.'
From an abstract point of view there is no need for uninterruptible
sleep since an uninterruptible sleep can be considered an interruptible sleep which clones a recovery thread and returns -EINTR, plus a little locking if needed.
Quoted 4 lines
What I'd _really_ like at the moment is an option to allow
read_inode()to be interruptible. Currently there's no way for it to exit without leaving a bad inode behind, which prevents the _next_iget()for that inode from actually succeeding.
If I remember rightly stat() is not interruptible anyway. I don't actually argue with the general claim. If I was redesigning unix right now I would have no blocking calls, just 'start_xyz' and wait/notify.
However the unix api as defined has certain limitations and assumptions we can pretty much never change. Open with O_INTR maybe would work ?
Alan
Hi,
Quoted 6 lines · Alan Cox
Quoted 4 lines
What I'd _really_ like at the moment is an option to allow
read_inode()to be interruptible. Currently there's no way for it to exit without leaving a bad inode behind, which prevents the _next_iget()for that inode from actually succeeding.If I remember rightly
stat()is not interruptible anyway.
It's possible to automatically restart stat(), so the process would be at least killable.
bye, Roman
Quoted 3 lines · Roman Zippel
It's possible to automatically restart
stat(), so the process would be at least killable.
Good point. The problem does indeed only arrive for a signal that is being caught and won't kill the process. That makes a lot of sense
Quoted 5 lines · [email protected] said:
Given an infinite number of monkeys yes. The 'disk I/O is not
interruptible' assumption is buried in vast amounts of software. This isnt a case of sorting out a few misbehaving applications, you can start with some of the most basic unix programs like 'ed' and work outwards.
Still probably worth doing in the long term. In the short term, we could possibly have a sysctl or personality flag to disable it for the benefit of broken software. I'm in favour of just letting it break though, to be honest - it's _already_ possible to trigger the breakage in some circumstances and making it more reproducible is a _good_ thing.
Quoted 3 lines
If I remember rightly
stat()is not interruptible anyway. I don't
actually argue with the general claim. If I was redesigning unix right now I would have no blocking calls, just 'start_xyz' and wait/notify.
stat() would be restartable. With -ERESTARTNOINTR would prevent us from ever actually returning -EINTR if the signal handler exists and returns.
I suspect open() would actually be more of a pain -- but that we could probably also restart if we get interrupted as early as the read_inode() stage.
You don't actually have to redesign the API, although I agree it could do with it. We could get rid of the bloody silly returning status _and_ length in one return code from read()/write() etc.
--
dwmw2
Quoted 8 lines · David Woodhouse
Quoted 5 lines · [email protected] said:
Given an infinite number of monkeys yes. The 'disk I/O is not
interruptible' assumption is buried in vast amounts of software. This isnt a case of sorting out a few misbehaving applications, you can start with some of the most basic unix programs like 'ed' and work outwards.
Quoted 5 lines
Still probably worth doing in the long term. In the short term, we could possibly have a sysctl or personality flag to disable it for the benefit of broken software. I'm in favour of just letting it break though, to be honest - it's _already_ possible to trigger the breakage in some circumstances and making it more reproducible is a _good_ thing.
If you really think this is important thing to do, I suggest you create a kernel patch which returns a partial read/write whenever the the size is even (and return an odd number of bytes), thus guaranteeing that 50% of the time, any I/O appears to have been interrupted.
Then run it on a system, and see what breaks. I wouldn't suggest doing this on any system that you care about, though!
- Ted
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
" " == Benjamin LaHaise <[email protected]> writes:
> Linux does not permit interrupting regular file reads on local > disks; only NFS supports it. Maybe 2.5 is the time to change > this.
Note that even the NFS support is less than perfect. Once a process enters lock_page(), there is no way for the user to interrupt until whatever I/O that is holding the page lock is finished.
Cheers,
Trond