> Lee Revell wrote:
>
> >On Tue, 2005-05-24 at 19:20 -0700, Andrew Morton wrote:
> >
> >>Sven Dietrich <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
