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]
Message-Id: <1240937745.3831.18.camel@alok-dev1>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ