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

> Lee Revell wrote:
>
> >On Tue, 2005-05-24 at 19:20 -0700, Andrew Morton wrote:
> >
> >>Sven Dietrich <sdietrich@mvista.com> 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 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/

\
 
 \ /
  Last update: 2005-05-25 05:40    [from the cache]
©2003-2011 Jasper Spaans