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: <1243532324.28705.75.camel@desktop>
Date:	Thu, 28 May 2009 10:38:44 -0700
From:	Daniel Walker <dwalker@...o99.com>
To:	Paul Mundt <lethal@...ux-sh.org>
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 Fri, 2009-05-29 at 01:58 +0900, Paul Mundt wrote:
> On Thu, May 28, 2009 at 09:52:27AM -0700, Daniel Walker wrote:
> > On Fri, 2009-05-29 at 01:40 +0900, Paul Mundt wrote:
> > > On Thu, May 28, 2009 at 06:32:09PM +0200, Peter Zijlstra wrote:
> > > > On Thu, 2009-05-28 at 09:13 -0700, Daniel Walker wrote:
> > > > > On Thu, 2009-05-28 at 14:59 +0200, Peter Zijlstra wrote:
> > > > > > CPU0                           CPU1
> > > > > > 
> > > > > > clock = ACCESS_ONCE(sched_clocksource);
> > > > > > 
> > > > > >                                unload module
> > > > > >                                  clocksource_unregister()
> > > > > >                                    sched_clocksource = jiffies
> > > > > >                                  unmap data/text
> > > > > > 
> > > > > > cyc2ns(clock, clocksource_read(clock)) <--- fireworks
> > > > > > 
> > > > > > 
> > > > > 
> > > > > Do any module based clocksources even exist right now?
> > > > > clocksource_unregister only seems to be used 3 times..
> > > > 
> > > > Good point, it appears its not even exported.
> > > > 
> > > > Thomas mentioned modules, I assumed.
> > > > 
> > > The drivers/clocksource/ drivers in theory could be modular anyways.
> > > Handling this transition properly is at least one less barrier to modular
> > > clocksources, so I think it's progress regardless. I don't remember what
> > > all of the other issues were though, John probably remembers.
> > 
> > I don't think it's an important case to consider right now ..
> > clocksources are usually so integral to the system putting one in a
> > module seems counterintuitive. 
> > 
> 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?

Daniel



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ