linux-kernel - Re: [PATCH] sched: Support current clocksource handling in fallback sched

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: <alpine.LFD.2.00.0905281943010.3397@localhost.localdomain>
Date:	Thu, 28 May 2009 19:46:22 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Daniel Walker <dwalker@...o99.com>
cc:	Paul Mundt <lethal@...ux-sh.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Linus Walleij <linus.ml.walleij@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Victor <linux@...im.org.za>,
	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-sh@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	John Stultz <johnstul@...ux.vnet.ibm.com>
Subject: Re: [PATCH] sched: Support current clocksource handling in fallback
 sched_clock().

On Thu, 28 May 2009, Daniel Walker wrote:
> > I would not have mentioned it if it weren't something we already had use
> > cases for. For the SH timers alone we have 3 that can be used as
> > clocksources in any combination, excluding the differences in timer
> > channels per block. These tend to have different implications for
> > performance, power management, etc.
> > 
> > The only reason they are not modular today is because more work needs to
> > be done to handle clocksources going away, or at least there was the last
> > time we tried it.
> 
> I don't know the details of SH so I can't speak specifically to that ..
> My experience is that usually one clock gets selected as the clocksource
> for a given system , and it rarely changes.. We have a sysfs facility to
> allow a user to switch clocksources, but I doubt that's used for more
> than debugging..
> 
> Can you imagine a general case on SH where the users know enough about
> the different clocksources that they can switch between them optimally
> without an SH expert sitting next to them telling them what to do?

Paul explained already that:

> > ...  These tend to have different implications for
> > performance, power management, etc.

So the use case for this is pretty obvious. In operational state you
want something fast and easy to access (which might use more power
e.g. because it runs at a higher clock frequency). When you go into
power saving modes you switch over to a clocksource which might be
slower to access but uses less power.

And there is no user interaction at all, it's selected as part of a
power state transition from the kernel.

Thanks,

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