Re: interrupt latency

Rik van Riel (H.H.vanRiel@phys.uu.nl)
Mon, 17 Aug 1998 19:25:30 +0200 (CEST)


On Sun, 16 Aug 1998, Kurt Garloff wrote:
> On Fri, Aug 14, 1998 at 08:58:15AM +0200, Marc SCHAEFER wrote:
> > However, if there is any process running (such as a niced rc5des),
> > it seems it can take upto 10ms (next timer tick) for the reschedule
> > to happen.
>
> You can change the HZ value in linux/include/asm-i386/param.h to higher
> values and recompile your kernel.

Perhaps a better option would be to change the type of bottom_half
used for processing the incoming data. IIRC, some kind of bottom
halves are processed only on a timer tick or on reschedule, doing
immediate processing of disk and tqueue bottom halves could improve
system performance instead of being a bottleneck (which was why they
were removed in the first place).

On a 16MHz 386/sx, it might have made sense to let the CPU continue
for a while before processing (in detail) the disk data, but on
modern systems it could be better to process everything first and
then do the switch to the I/O bound process. This gives greater
parallelization, better I/O performance and thus a shorter task
run and maybe better performance.

Alternatively, we can test whether the priority for the current
task is < DEF_PRIORITY/2 before deciding whether to run the
bottom_half or not, but this might actually be more expensive
than just running it :)

Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html