Re: Blocking read() policy?

From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 07/23/05 

Date: Sat, 23 Jul 2005 21:10:45 +0200

Robert Redelmeier wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
> >
> > It doesn't require any particular advanced scheduler. The
> > scheduler have supported blocking for as long as I have
> > been using Linux and probably a lot longer than that.
>
> Yes, blocking has been supported for eons.
> However, immediate unblocking has not.

That feature has existed since linux-0.96a.

>
> The scheduler is the very heart of the OS. It sets much of
> the performance characteristics. It should use all availabe
> data in making rescheduling decisions. Including syscall
> frequency and types.

Quite the contrary. The scheduler should be kept
as simple as possible. Then you can build good
stuff on top of it. What happens in the read
system call is just something that happens on top
of the scheduler. The scheduler shouldn't worry
about the exact details of it, exactly like it
shouldn't worry about exact details of application
design.

>
> For a different example, a process that makes very few syscalls
> is probably doing a crunch of some kind. Those need CPU clocks
> but not low latency. They could be schedules for longer slices
> less frequently. Especially if pgms demanding short latency
> could get immediate service after unblocking interrupts.

It is correct, that a CPU intensive process would
usually perform better with long slices. But the
right way to detect that is by realizing how
rarely it sleeps.

Once concrete algorithm, which AFAIR is described
in a book by Tanenbaum does the following: Each
time a process use a full time slice, the length
of the time slices for that process is doubled.
This repeats until it blocks at which point it
starts over with the shortest possible time slice.
However the CPU is always given to a process in
the queue with the shortest time slices, only
when they have all blocked or used up their slice
you go to the next queue. (Probably I didn't
remember all the details, but I guess you get the
overall idea).

Of course the latency requirements means there is
a limit to how long the slices will get. At least
on a single CPU system. On a dual CPU system you
could be lucky and not need both CPUs at once for
processes with small CPU requirements.

>
> Think of a case where data is arriving at a more
> or less constant rate. An app more concerned with bandwidth
> than latency would be better if the kernel accumulated bigger
> buffers rather than rescheduling every packet.

Often such applications are really limited by the
network bandwidth and not the CPU. Those situations
that need both large amounts of CPU time and
communication, are better dealt with in user mode
than in kernel mode. 

-- 
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

Relevant Pages

  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ... shorter first time slice gives the scheduler a chance to reassess the ... This is supposed to represent the task with the highest CPU usage rate per share and is used to determine how fairly CPU is being distributed among the currently active tasks. ...
    (Linux-Kernel)
  • Re: BFS vs. mainline scheduler benchmarks and measurements
    ... Nikos Chantziaraswrote: ... scheduler delays ... this is on an Intel Core 2 Duo CPU. ... now the interesting part is also WHERE the latency hits. ...
    (Linux-Kernel)
  • Re: fixed time slices?
    ... | to finish using its time slice), and assigns a full time slice ... become ready to run, and be scheduled on a CPU, when the scheduler is ... So it could put the CPU on ... the timer frequency. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
    ... latency compared to other processes at the same static priority. ... The alternative to fairness is arbitrary ... the user would prefer a task to get more CPU and try to give it more. ... Then you will always get cases where the scheduler does not do what the user ...
    (Linux-Kernel)
  • Re: BFS vs. mainline scheduler benchmarks and measurements
    ... scheduler delays ... this is on an Intel Core 2 Duo CPU. ... now the interesting part is also WHERE the latency hits. ... Deciding who gets to run first/more; eg priority between apps ...
    (Linux-Kernel)
Loading