linux-kernel - Re: [RFC PATCH 0/1]: timers: Timer Migration

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:	Wed, 17 Sep 2008 10:31:51 +0530
From:	Arun R Bharadwaj <arun@...ux.vnet.ibm.com>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	ego@...ibm.com, tglx@...utronix.de, mingo@...e.hu,
	a.p.zijlstra@...llo.nl, andi@...stfloor.org,
	venkatesh.pallipadi@...el.com, vatsa@...ux.vnet.ibm.com
Subject: Re: [RFC PATCH 0/1]: timers: Timer Migration

Arjan van de Ven wrote:
> On Tue, 16 Sep 2008 14:42:31 +0530
> Arun R Bharadwaj <arun@...ux.vnet.ibm.com> wrote:
>
>   
>> Hi,
>>
>> An idle cpu on which device drivers have initialized timers, has to
>> be frequently woken up to service the timers. So, consolidation of
>> timers onto a fewer number of cpus is important. Migration of timers
>> from idle cpus onto lesser idle cpus is necessary. Currently, timers
>> are migrated during the cpu offline operation. However cpu-hotplug
>> for the sake of idle system power management is too heavy. So, this
>> patch implements a lightweight timer migration framework.
>>     
>
> while I absolutely like reducing power consumption... I'm not sure this
> helps or is the right approach.
>
> First of all, it's of course absolutely better to fix timers and apps
> that cause them (and with PowerTOP we fixed basically all the bad
> stuff).
>
> Second, in terms of power; a wake up is a wake up, it doesn't really
> matter where it happens. 
>   


This is a very valid point. The algorithm which decides which cpu to
migrate the timers to should be intelligent enough in the sense that it
migrates *only* when there is some benefit out of it. That is, the cpu
to which the timers are being migrated, is sufficiently busy and it is
not unnecessarily brought out of its idle state. Else, as you pointed
out, the penalty of wake up is same for either of the cpu.


> Now we could do some consolidation (which realistically needs the range
> timer feature that's aimed for 2.6.28), but I would much rather do that
> in a different way: rather than actively moving stuff, I would instead
> suggest sharing the timer queues between logical cpus that share the
> same cache. (Now its an admin choice if he wants this on a "shared L1",
> "shared L2" or "shared L3" basis). 
>   


While migrating range timers, I would migrate only if the time range of
the source and destination cpus match. Else, there is no point in
migrating. I would rather look at timer migration as an optimization
strategy to increase the cpu idle time and not as a pro-active method to
rid the cpu of timers, no matter what. I would like to migrate timers
only if the wake up penalty of the system as a whole decreases.


> Or if you want to forcefully migrate timers, don't move existing ones,
> just on queue/requeue put the on not-the-local-cpu. Sure they'll fire
> once on the "wrong" cpu, but that's a very short term problem!
>
>   

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