public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kurt Garloff <K.Garloff@ping.de>
To: scherrey@proteus-tech.com
Cc: Linux kernel list <linux-kernel@vger.rutgers.edu>
Subject: Re: [PATCH] HZ change for ix86
Date: Wed, 6 Jan 1999 10:41:18 +0100	[thread overview]
Message-ID: <19990106104118.B27572@kg1.ping.de> (raw)
In-Reply-To: <3692DF1C.C03DD162@gte.net>; from Benjamin Scherrey on Tue, Jan 05, 1999 at 10:57:16PM -0500

On Tue, Jan 05, 1999 at 10:57:16PM -0500, Benjamin Scherrey wrote:
> Kurt -
> 
>     Thanx for the insightful information about the impact of changing the HZ
> values. Questions: a) how platform specific is this setting (i86, ALPHA, et al),
> and b) Does increasing the HZ value increases context switches or increases
> duration of each context?

a)
The HZ value differs between the different architectures. The alpha has e.g.
HZ set to 1024. That's why the kernel core has to independent of it.
The way I coded it, it will break compilation on other archs, as I was to
lazy to put the constant HZ_TO_STD into the header files of other archs.
Of course, we could use something like #ifndef HZ_TO_STD #define HZ_TO_STD 1
#endif in kernel/sys.c

b)
The timer interrupt and therefore the scheduler will be called more often.
If more than one process competes for CPU (R state), than the number of
switches between these processes will occur more often, about 4 times as
often.
If I understood correctly, also the bottom half data processing of the
kernel is tied to the timer interrupt and will thus happen more often.

It speeded up some of my numerical computations on my SMP machine, BTW. I
have rc5des runnning (idle priority, Rik's patch), and some threads sleeping
and waiting for some job to be submitted to them. However, after they were
signalled, they will only start after the next scheduler tick. So the HZ
value influences scheduling latency. Unfortunately my program is not very
well parallelized, so the jobs to be done by the threads are very short and
take about the same time as the scheduler latency. Now, with 400 Hz it was
much better ...

>     This sounds like an excellent developer's config option to me.... Any
> chance of this happening soon?

This is not up to me. 
I can however create a cleaned up patch and put it on my website, if enough
people want it. It will take some days, though, as I'm very busy.

Regards,
-- 
Kurt Garloff <kurt@garloff.de>                           [Dortmund, FRG]  
Plasma physics, high perf. computing              [Linux-ix86,-axp, DUX]
PGP key on http://www.garloff.de/kurt/        [Linux SCSI driver: DC390]

-
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/

  reply	other threads:[~1999-01-07  2:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-05  8:48 [PATCH] HZ change for ix86 Kurt Garloff
1999-01-06  3:57 ` Benjamin Scherrey
1999-01-06  9:41   ` Kurt Garloff [this message]
1999-01-07  9:54   ` Chris Wedgwood
1999-01-06  5:25 ` B. James Phillippe
1999-01-06  9:29   ` Kurt Garloff
1999-01-07 13:09     ` Pavel Machek
1999-01-08 14:14       ` Richard B. Johnson
1999-01-08 22:23         ` Kurt Garloff
1999-01-07  9:56   ` Chris Wedgwood
1999-01-07 17:38   ` Riley Williams
1999-01-06  8:21 ` Egil Kvaleberg
1999-01-07 17:56   ` Dan Kegel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19990106104118.B27572@kg1.ping.de \
    --to=k.garloff@ping.de \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=scherrey@proteus-tech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox