On 03/04/2013 10:31 AM, Adam Jackson wrote:
On Sun, 2013-03-03 at 07:18 -0500, Prarit Bhargava wrote:
> Do we need this anymore, or can it be dropped to something more reasonable like
> HZ=100 or HZ=250?
> Does anyone have an actual issue where they require HZ=1000?
I guess it depends what the implementation actually does. What does HZ
even control these days? If it controls the scheduler timeslice then
yes I very much do need 1kHz, xserver needs to be able to post a buffer
swap at least every 16ms and if the scheduler only task-switches every
10ms then I stand a very good chance of dropping frames.
IIRC, the scheduler timeslice isn't impacted by HZ. There's a definition of the
default timeslice, RRTIMESLICE or something like that (brain fail me.) which
takes into account that HZ is really some number of events per second, rather
than just some number of events.
(brain ... still ... fail. ... not RRTIMESLICE ... geez.)
I'm going to end up owing someone a beer when they tell me what that default is...
Why do you want it lower?
You know me ;) Always thinking of big systems :)
Some HPC colleagues (who would strongly prefer to use Fedora instead of another
OS) mentioned to me that they can actually "see" the effect of having HZ @
While thing have gotten better, the bottom line appears to be that there is a
noticeable impact to performance on compute nodes due to acquiring of the clock
related locks in the timer interrupt code path when you have 1000s of physical cpus.
So I took a look at some of the other Linux OSes (Ubuntu, OpenSuse) and the
major ones seem to be at HZ=250. I'm wondering if there is an actual real
reason we still have it at 1000 or if this is a purely historical value?
Aside: I had heard from SGI in the past year that they also noticed some
problems with the locking @ HZ=1000, however, I'm certain those issues have been
resolved upstream. It seems like for most performance situations we're okay @
1000, but there are some circumstances where 1000 still won't cut it.
I've advised them to compile their own kernel with a lower value of HZ. But, as
you can imagine, that isn't exactly the best option for them.