Re: Overscheduling DOES happen with high web server load.

Phillip Ezolt (ezolt@perf.zko.dec.com)
Fri, 7 May 1999 15:12:26 -0400 (EDT)


Kurt,
> 3) There might still be cases where processes should be scheduled ASAP but
> are only on the next scheduler tick. I got some multithreaded (pthreads)
> numerical benchmark which depends on the HZ setting. (At least it did,
> when I last tested (2.2.2 or smth similar), but maybe Ingo has changed
> something soince then.)
> This is the reason for my HZ=400 on ix86 patch.
> http://www.garloff.de/kurt/linux/
>

This is very interesting information. It seems that interrupt handling
begins to get expensive as you ratchet up the HZ. It looks like your
numerical benchmark may want to push it up, while other benchmarks might
want to push it down. Actually, it would be advantageous to decrease HZ or
decrease the cost of an interrupt.

--Phil

Digital/Compaq: HPSD/Benchmark Performance Engineering
Phillip.Ezolt@compaq.com ezolt@perf.zko.dec.com

On Fri, 7 May 1999, Kurt Garloff wrote:

> On Fri, May 07, 1999 at 03:34:56AM -0700, Jim Gettys wrote:
> > 100hz == 10 ms == about 1/3 - 1/6 of human perception or your latency
> > budget for actions to be percieved as truly "instantaneous"; you
> > never can get latency back.
> >
> > Given Jay's recent mail on the topic, I think things jibe with my memory:
> > the console is set that high in large part since we run that fast on other
> > operating systems; this got set as part of the initial experiments when
> > porting to new architectures; the cost of running at a high basic
> > rate is low enough that this was a rational design decision.
> > - Jim
>
> 1) Please note that the overscheduling problem was NOT caused by HZ being
> high. (I guess you know, I just wanted to point out again.)
> 2) The kernel can wake up processes immediately, if they blocked on I/O
> before, orif they get a signal, so the interactive feeling does not
> necessarily on HZ. From what I know, the Linux kernel does it that way.
> 3) There might still be cases where processes should be scheduled ASAP but
> are only on the next scheduler tick. I got some multithreaded (pthreads)
> numerical benchmark which depends on the HZ setting. (At least it did,
> when I last tested (2.2.2 or smth similar), but maybe Ingo has changed
> something soince then.)
> This is the reason for my HZ=400 on ix86 patch.
> http://www.garloff.de/kurt/linux/
>
> Regards,
> --
> Kurt Garloff <garloff@suse.de> SuSE GmbH, Nürnberg, FRG
> Linux kernel development; SCSI driver: DC390 (tmscsim/AM53C974)
>

-
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.tux.org/lkml/