[lkml]   [2005]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: RT patch acceptance

> Lee Revell wrote:
> >On Tue, 2005-05-24 at 19:20 -0700, Andrew Morton wrote:
> >
> >>Sven Dietrich <> wrote:
> >>
> >>>I think people would find their system responsiveness /
> tunability
> >>>goes up tremendously, if you drop just a few unimportant
> IRQs into
> >>>threads.
> >>>
> >>People cannot detect the difference between 1000usec and 50usec
> >>latencies, so they aren't going to notice any changes in
> >>responsiveness at all.
> >>
> >
> >The IDE IRQ handler can in fact run for several ms, which
> people sure
> >can detect.
> >
> >
> Are you serious? Even at 10ms, the monitor refresh rate would
> have to be over 100Hz for anyone to "notice" anything,
> right?... What sort of numbers are you talking when you say several?

Even without numbers, the IDE IRQ, when run in a thread,
competes with tasks at process level, so that other
tasks can make some progress. Especially if those tasks are
high priority.

With multiple disks on a chain, you can see transients that
lock up the CPU in IRQ mode for human-perceptible time,
especially on slower CPUs...

This is part of the reason why SoftIRQd exists: to act as
a governor for bottom halves that run over and over again.
SoftIRQd handles those bursty bottom halves in task space.

So with that, you already have bottom halves in threads.

Then we are just talking about the concept of running the
top-half in a thread as well.

Maybe Lee will have some numbers handy...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-05-25 05:40    [W:0.255 / U:0.068 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site