From arne_woerner at yahoo.com  Thu Nov 11 10:14:49 2004
From: arne_woerner at yahoo.com (Arne Wörner)
Date: Thu Nov 11 10:14:50 2004
Subject: system calls
Message-ID: <20041111181446.64684.qmail@web41215.mail.yahoo.com>

Hiho!

I just read in the BUGS section of the man page of rtprio(1), that system calls
are never preemted.

Does that mean, that a "read(fd,buffer,10000000)" blocks all other processes,
until 10^7 bytes are read even if fd points to a file on a very slow and huge
floppy disc?

Does that mean, that no process can run, after the kernel ordered a hard disc
to move its heads until the data is transfer from disc to memory (sometimes it
feels like :) )?

Unfortunately I am quite sure, that I would not find out the truth by
experimentation or by looking at source code. Sorry...

If at least one answer is "yes", then I think, that it would be much better for
the performance, if processes could run, while the kernel manages lengthy
io-ops (I still remember, that there was a picture about 4 process states:
running, waiting, dead, blocked; and while the blocked processes are blocking,
the waiting processes are competiting for the CPU/-s).

Thanks.

Bye
Arne



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 

From bde at zeta.org.au  Fri Nov 12 08:22:01 2004
From: bde at zeta.org.au (Bruce Evans)
Date: Fri Nov 12 08:22:03 2004
Subject: system calls
In-Reply-To: <20041111181446.64684.qmail@web41215.mail.yahoo.com>
References: <20041111181446.64684.qmail@web41215.mail.yahoo.com>
Message-ID: <20041113025019.Q2310@epsplex.bde.org>

On Thu, 11 Nov 2004, Arne W=F6rner wrote:

> Hiho!
>
> I just read in the BUGS section of the man page of rtprio(1), that system=
 calls
> are never preemted.

This is out of date.  System calls are sometimes preempted in -current.

> Does that mean, that a "read(fd,buffer,10000000)" blocks all other proces=
ses,
> until 10^7 bytes are read even if fd points to a file on a very slow and =
huge
> floppy disc?

It meant that long ago when 10^7 bytes was a lot of memory and took
about 1 second to read from /dev/zero.  The problem was worked around
for some syscalls by giving up control every few ticks (every 1/5
second, which is more than a few (?)) in uiomove().  Things work
a little differently in -current.  The timeout for giving up control
is broken since it is reset on every context switch and -current
switches contexts too much (on every non-fast interrupt...); thus
the timeout rarely expires.  However, switching contexts preempts
the process often enough.

Core dumps were fixed similarly.

> Unfortunately I am quite sure, that I would not find out the truth by
> experimentation or by looking at source code. Sorry...

Try looking at the gzip image activator and large sysctls, and running
them under non-current.

gunzipping takes much longer than copying out data.  It's possible to
have a tiny input file that wants to expand to many gigabytes in memory
to run.  If it is too big then it won't fit but the gzip image activator
will take a long time to expand the part that fits.

Almost any sysctl that copies out a huge amount of data and doesn't
explictly give up control will not be preempted for too long.  I've
written too many such sysctls for debugging.  Typically they print out
trace buffers in a human readable form.  Formatting (printf) takes
much longer than copying, and I sometimes make the trace buffers larger
(several MB) giving possibly hundreds of MB of output.

Bruce