system calls

Bruce Evans bde at
Fri Nov 12 08:22:01 PST 2004

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=
> 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=
> until 10^7 bytes are read even if fd points to a file on a very slow and =
> 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.


More information about the freebsd-realtime mailing list