linux-kernel - Re: [v7 0/8] Reduce cross CPU IPI interference

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:	Thu, 9 Feb 2012 10:59:45 -0500
From:	Chris Metcalf <cmetcalf@...era.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
CC:	Christoph Lameter <cl@...ux.com>,
	Gilad Ben-Yossef <gilad@...yossef.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	Pekka Enberg <penberg@...nel.org>,
	Matt Mackall <mpm@...enic.com>,
	Sasha Levin <levinsasha928@...il.com>,
	Rik van Riel <riel@...hat.com>,
	Andi Kleen <andi@...stfloor.org>, Mel Gorman <mel@....ul.ie>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Avi Kivity <avi@...hat.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	Kosaki Motohiro <kosaki.motohiro@...il.com>,
	Milton Miller <miltonm@....com>
Subject: Re: [v7 0/8] Reduce cross CPU IPI interference

On 2/9/2012 10:52 AM, Frederic Weisbecker wrote:
> On Thu, Feb 02, 2012 at 10:29:57AM -0600, Christoph Lameter wrote:
>> On Thu, 2 Feb 2012, Frederic Weisbecker wrote:
>>
>>>> Some pinned timers might be able to get special treatment as well - take for
>>>> example the vmstat work being schedule every second, what should we do with
>>>> it for CPU isolation?
>>> Right, I remember I saw these vmstat timers on my way when I tried to get 0
>>> interrupts on a CPU.
>>>
>>> I think all these timers need to be carefully reviewed before doing anything.
>>> But we certainly shouldn't adopt the behaviour of migrating timers by default.
>>>
>>> Some timers really needs to stay on the expected CPU. Note that some
>>> timers may be shutdown by CPU hotplug callbacks. Those wouldn't be migrated
>>> in case of CPU offlining. We need to keep them.
>>>
>>>> It makes sense to me to have that stop scheduling itself when we have the tick
>>>> disabled for both idle and a nohz task.
>> The vmstat timer only makes sense when the OS is doing something on the
>> processor. Otherwise if no counters are incremented and the page and slab
>> allocator caches are empty then there is no need to run the vmstat timer.
> So this is a typical example of a timer we want to shutdown when the CPU is idle
> but we want to keep it running when we run in adaptive tickless mode (ie: shutdown
> the tick while the CPU is busy).

We would want to stop the timer as long as the processor is running
exclusively userspace code.  Christoph's point is that in either the idle
case or the userspace-only case, the vmstats won't be incrementing anyway. 
Presumably you'd restart the timer when you enter the kernel, then when it
fires and does its work, you might notice that when you return to userspace
no further information will be collected, so stop the timer at that point. 
Or, perhaps you could just proactively call refresh_cpu_vm_stats() just
before stopping the tick and returning "permanently" to userspace, to make
sure the stats are all properly updated.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

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