linux-kernel - Re: [PATCH documentation 1/2] nohz1: Add documentation.

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:	Mon, 15 Apr 2013 09:41:19 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Christoph Lameter <cl@...ux.com>
CC:	paulmck@...ux.vnet.ibm.com, Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
	mingo@...e.hu, laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...ymtl.ca,
	josh@...htriplett.org, niv@...ibm.com, tglx@...utronix.de,
	rostedt@...dmis.org, Valdis.Kletnieks@...edu, dhowells@...hat.com,
	edumazet@...gle.com, darren@...art.com, fweisbec@...il.com,
	sbw@....edu, Kevin Hilman <khilman@...aro.org>
Subject: Re: [PATCH documentation 1/2] nohz1: Add documentation.

On 4/15/2013 9:00 AM, Christoph Lameter wrote:
> On Fri, 12 Apr 2013, Arjan van de Ven wrote:
>
>> but arguably, that's because of HRTIMERS more than NOHZ
>> (e.g. I bet we still turn off periodic even for nohz as long as hrtimers are
>> enabled)
>
> If we are able to only get rid of one timer tick on average with dynticks
> then I would think that is enough to justify having it on by default.
>
> If the scheduling period from the schduler is around 20ms then one may be
> able to save processing 20 timer ticks by going to htimers.
>
> The main issue with hrtimers is likely going to be that is it is too much
> effort for small timerframes less than 10ms. Could we  only switch off the
> timer tick if the next event is more than 10 ticks aways?
>

to put the "cost" into perspective; programming a timer in one-shot mode
is some math on the cpu (to go from kernel time to hardware time),
which is a multiply and a shift (or a divide), and then actually
programming the hardware, which is at the cost of (approximately) a cachemiss or two
(so give or take in the "hundreds" of cycles)
at least on moderately modern hardware (e.g. last few years)

not cheap. But also not INSANE expensive... and it breaks-even already if you only
save one or two cache misses elsewhere.

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