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: <20090528182730.GA32767@linux-sh.org>
Date:	Fri, 29 May 2009 03:27:33 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Daniel Walker <dwalker@...o99.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	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, May 28, 2009 at 11:10:52AM -0700, Daniel Walker wrote:
> On Fri, 2009-05-29 at 02:53 +0900, Paul Mundt wrote:
> > Yes, we want to be able to use modular clocksources. The only reason we
> > don't right now is because some more preparatory work is needed first.
> > Any attempt to remove support for modular clocksources means we will just
> > have to add it in back later.
> 
> This is what's difficult to understand.. You have multiple clocks ok,
> fine.. You have multiple clocks that you want the kernel to switch
> between, ok that's fine too.. What's missing is the case where
> clocksource modules being loaded/unload via the user becomes a valuable
> use case..
> 
> If you have a valuable use case for that, fine, I won't stand in the
> way ..
> 
Ah, ok, I suppose I could have explained that better. There are a couple
of different considerations really. The timer blocks are often in
different clock and power domains, meaning that only certain ones can be
used for wakeups. These tend not to be ideal for general use, and so we
only switch to them when we have to.

To make matters more convoluted, the availability of different timer
channels on different CPUs will depend on current pin state, and more
importantly, what sort of states we are able to achieve. It is not
uncommon to have some of the pins required by these channels locked down
by other drivers during regular operation, which we in turn need to
unload before the pin state can be reconfigured and the timer can
succeed, all which needs to happen before certain power state transitions
can take place. We implement dynamic pinmux for most of the SH CPUs
precisely to deal with these sorts of problems. In the case of some of
the microcontrollers that are timer heavy and low on pincount, it is not
uncommon to have upwards of 16 different functions per pin.
--
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/