yodaiken@fsmlabs.com wrote:
>
> On Mon, Jan 14, 2002 at 03:21:14PM -0800, george anzinger wrote:
> > > > How is that changed? AFAIK inserting more schedule points does not
> > > > change the behaviour of the scheduler. The niced app will still get its
> > > > time.
> > >
> > > How many times can an app be preempted? In a non preempt kernel
> > > is can be preempted during user mode at timer frequency and no more
> >
> > Uh, it can be and is preempted in user mode by ANY interrupt, be it
> > keyboard, serial, lan, disc, etc. The kernel looks for need_resched at
> > the end of ALL interrupts, not just the timer interrupt.
>
> Ouch.
Ouch? It is supposed to be that way. Consider:
A high-priority task issues a disk read - and blocks. Some
lower-priority process gets the cpu. But then the disk io finishes
way before the low-priority process used up its timeslice.
The kernel gets an interrupt from the disk controller because
of that. Perhaps the block device issues some more requests,
then time comes to return to user space. The higher priority task
is now ready to run because its IO completed. So of course
it is preferred over that low-priority thing. In other words,
the low-priority task got preempted, this time by a disk
interrupt.
The same thing happens whan high-priority tasks waits for
other kinds of io, such as network, serial, and so on.
I am sure you wouldn't want it any other way. Not
using the opportunity to switch task immediately after an io
completion interrupt would kill latency completely.
Helge Hafting
-
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/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:50 EST