linux-kernel - Re: Default HZ value for X86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Apr 2009 09:55:45 -0700
From:	Alok Kataria <akataria@...are.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Default HZ value for X86

On Mon, 2009-04-27 at 16:34 -0700, Alan Cox wrote:
> On Mon, 27 Apr 2009 16:07:10 -0700
> Alok Kataria <akataria@...are.com> wrote:
> 
> > Hi, 
> > 
> > I was wondering why do we still have the default HZ value as 1000 for
> > the x86 kernels.
> > 
> > arch/x86/configs/i386_defconfig:CONFIG_HZ=1000
> > arch/x86/configs/x86_64_defconfig:CONFIG_HZ=1000
> > 
> > With the highres timer implementation it was planned to move away from
> > relying on high timer interrupt frequency for applications requiring
> > precise high resolution timers.
> 
> With the tickless kernel does this really matter any more ? 

Agreed that with tickless it won't be an issue anymore when the system
is idle, but when the system is loaded the interrupts will still fire at
HZ frequency. 
I ran a simple tight loop to check what kind of effect would the HZ
value have on system performance. This tight loop was run on a 2.6.29
kernel running under VMware looping till count of 6X10^9. 
The one with HZ = 1000 took about 4m 24s, (264sec) 
Total timer interrupts = 264405

And the one with HZ = 100 took about 4m 15s (255sec)
Total timer interrupts = 25593.

Please note that the system was booted in a single user mode and only
the minimal services were running to reduce any interference from any
other process. These numbers are averaged across 3 runs.

The cost of servicing an interrupt would be a little higher in the
virtualized environment, so I am not sure if it would have a similar
impact on a real hardware. 
So this mail is more to understand if there could be any real downsides
with reducing the Hz value, FWIU it shouldn't affect the correctness of
the system right ?

> We might as
> well keep a logical 1000 for convenience and accuracy.

What is the accuracy factor that you are mentioning here ? i guess you
mean the precision of the timeouts, but that shouldn't matter much
right ? 

Thanks,
Alok
> 
> Alan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/