wait queue process state

wait queue process state

[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

Re: wait queue process state

[William Lee Irwin III]

On Mon, May 27, 2002 at 05:11:23PM -0400, Joseph Cordina wrote:
> 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

Re: wait queue process state

[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.


Make sense?

TJ
 

On Mon, 2002-05-27 at 23:11, Joseph Cordina wrote:
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
_________________________________________________________________________

Terje Eggestad                  mailto:terje.eggestad@scali.no
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            
_________________________________________________________________________

Re: wait queue process state

[jw schultz]

On Tue, May 28, 2002 at 09:57:41AM +0200, Terje Eggestad wrote:
> 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

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.


>  
> 
> On Mon, 2002-05-27 at 23:11, Joseph Cordina wrote:
> > 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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> -- 
> _________________________________________________________________________
> 
> Terje Eggestad                  mailto:terje.eggestad@scali.no
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: wait queue process state

[Benjamin LaHaise]

On Tue, May 28, 2002 at 04:01:43PM -0700, jw schultz wrote:
> 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

Re: wait queue process state

[Alan Cox]

On Wed, 2002-05-29 at 00:05, Benjamin LaHaise wrote:
> On Tue, May 28, 2002 at 04:01:43PM -0700, jw schultz wrote:
> > 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

Re: wait queue process state

[David Woodhouse]

alan@lxorguk.ukuu.org.uk 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

Re: wait queue process state

[Alan Cox]

On Wed, 2002-05-29 at 11:58, David Woodhouse wrote:
> 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.

> 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.

> 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

Re: wait queue process state

[Roman Zippel]

Hi,

On 29 May 2002, Alan Cox wrote:

> > 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

Re: wait queue process state

[Alan Cox]

On Wed, 2002-05-29 at 12:55, Roman Zippel wrote:
> 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

Re: wait queue process state

[David Woodhouse]

alan@lxorguk.ukuu.org.uk 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.

>  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

Re: wait queue process state

[Theodore Ts'o]

On Wed, May 29, 2002 at 12:56:03PM +0100, David Woodhouse wrote:
> 
> alan@lxorguk.ukuu.org.uk 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.

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

Re: wait queue process state

[Trond Myklebust]

>>>>> " " == Benjamin LaHaise <bcrl@redhat.com> 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