| Message ID | 20090528124207.GA28830@linux-sh.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Thu, 28 May 2009, Paul Mundt wrote: > On Thu, May 28, 2009 at 02:22:17PM +0200, Thomas Gleixner wrote: > > On Thu, 28 May 2009, Paul Mundt wrote: > > > @@ -437,10 +441,19 @@ void clocksource_unregister(struct clocksource *cs) > > > unsigned long flags; > > > > > > spin_lock_irqsave(&clocksource_lock, flags); > > > + > > > + if (sched_clocksource == cs) { > > > + printk(KERN_WARNING "Refusing to unregister " > > > + "scheduler clocksource %s", cs->name); > > > > Hmm, isn't that dangerous ? The clocksource might be in a module or > > in kmalloced memory which is going to be freed. > > > Perhaps the saner thing to do is see if select_clocksource() manages to > find something suitable, otherwise switch back to jiffies.. That makes sense. The scheduler should be able handle that, if not ... :) Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2009-05-28 at 21:42 +0900, Paul Mundt wrote: > unsigned long long __attribute__((weak)) sched_clock(void) > { > - return (unsigned long long)(jiffies - INITIAL_JIFFIES) > - * (NSEC_PER_SEC / HZ); > + struct clocksource *clock = ACCESS_ONCE(sched_clocksource); > + > + return cyc2ns(clock, clocksource_read(clock)); > } > > @@ -440,7 +444,17 @@ void clocksource_unregister(struct clocksource *cs) > list_del(&cs->list); > if (clocksource_override == cs) > clocksource_override = NULL; > + > next_clocksource = select_clocksource(); > + > + /* > + * If select_clocksource() fails to find another suitable > + * clocksource for sched_clocksource and we are unregistering > + * it, switch back to jiffies. > + */ > + if (sched_clocksource == cs) > + sched_clocksource = &clocksource_jiffies; > + > spin_unlock_irqrestore(&clocksource_lock, flags); > } CPU0 CPU1 clock = ACCESS_ONCE(sched_clocksource); unload module clocksource_unregister() sched_clocksource = jiffies unmap data/text cyc2ns(clock, clocksource_read(clock)) <--- fireworks -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 28 May 2009, Daniel Walker wrote: > > > > 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. That does not matter at all. If we have an unregister call then we have to be prepared for - the memory which contained the clocksource is freed - the underlying hardware is going away. It does not matter at all if that happens in a compiled in or in a modular driver. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Yea. Its always been something I'd want to have as a capability, but we haven't actually had a user of. I still think its something we should allow, even if there aren't upstream users, as if you only have to backport a module to an old distro kernel to get some oddball bit of hardware working, that can be really useful. So I think the locking fix is the way to go. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 28, 2009 at 10:38:44AM -0700, Daniel Walker wrote: > 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: > > > 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? > As I already stated, yes. We have multiple clock sources for most CPUs. These can be set up in any sort of configuration, and there are pros and cons to using different ones. The ones that are available can in turn be cycled between. I don't know what exactly is difficult to understand about this. 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. That and the fact there are already in-tree users using the unregistration path suggests that there is no benefit in trying to prevent modular clocksources in the first place. If you have no intention to use modular clocksources, then don't. If you have any technical concerns, then raise them, otherwise this is pointless. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2009-05-29 at 02:53 +0900, Paul Mundt wrote: > As I already stated, yes. > > We have multiple clock sources for most CPUs. These can be set up in any > sort of configuration, and there are pros and cons to using different > ones. The ones that are available can in turn be cycled between. I don't > know what exactly is difficult to understand about this. I understand that cpu's can have multiple clocks, that's not a hard concept to grasp. > 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 .. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 28 May 2009, Daniel Walker wrote: > On Fri, 2009-05-29 at 02:53 +0900, Paul Mundt wrote: > > > As I already stated, yes. > > > > We have multiple clock sources for most CPUs. These can be set up in any > > sort of configuration, and there are pros and cons to using different > > ones. The ones that are available can in turn be cycled between. I don't > > know what exactly is difficult to understand about this. > > I understand that cpu's can have multiple clocks, that's not a hard concept to grasp. > > > 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.. Did you actually read what people wrote ? This is not about modules or not, it's about safe switching of clocksources when they are used for sched_clock as well. > If you have a valuable use case for that, fine, I won't stand in the > way .. Sigh, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2009-05-29 at 03:27 +0900, Paul Mundt wrote: > 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. I'm still a little confused how kernel modules fit in here.. Are you saying a user would unload some certain driver which has a pin locked down and prevents the clocksource from working. Then the user would load the clocksource module which would now function, and that all would have to happen in order to enter a certain power state? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 28, 2009 at 12:04:23PM -0700, Daniel Walker wrote: > On Fri, 2009-05-29 at 03:27 +0900, Paul Mundt wrote: > > > 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. > > I'm still a little confused how kernel modules fit in here.. Are you > saying a user would unload some certain driver which has a pin locked > down and prevents the clocksource from working. Then the user would load > the clocksource module which would now function, and that all would have > to happen in order to enter a certain power state? > Yes. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2009-05-29 at 04:34 +0900, Paul Mundt wrote: > > I'm still a little confused how kernel modules fit in here.. Are you > > saying a user would unload some certain driver which has a pin locked > > down and prevents the clocksource from working. Then the user would load > > the clocksource module which would now function, and that all would have > > to happen in order to enter a certain power state? > > > Yes. I'm assuming this isn't a low power state, this would be something more like suspend or hibernate right? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 28, 2009 at 12:41:03PM -0700, Daniel Walker wrote: > On Fri, 2009-05-29 at 04:34 +0900, Paul Mundt wrote: > > > I'm still a little confused how kernel modules fit in here.. Are you > > > saying a user would unload some certain driver which has a pin locked > > > down and prevents the clocksource from working. Then the user would load > > > the clocksource module which would now function, and that all would have > > > to happen in order to enter a certain power state? > > > > > Yes. > > I'm assuming this isn't a low power state, this would be something more > like suspend or hibernate right? > Right, with the amount of hassle involved, it makes no sense for run-time PM at least. So the suspend/hibernate use cases are mostly where it makes sense. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h index c56457c..2109940 100644 --- a/include/linux/clocksource.h +++ b/include/linux/clocksource.h @@ -202,7 +202,8 @@ struct clocksource { #endif }; -extern struct clocksource *clock; /* current clocksource */ +extern struct clocksource *clock; /* current clocksource */ +extern struct clocksource *sched_clocksource; /* sched_clock() clocksource */ /* * Clock source flags bits:: @@ -212,6 +213,7 @@ extern struct clocksource *clock; /* current clocksource */ #define CLOCK_SOURCE_WATCHDOG 0x10 #define CLOCK_SOURCE_VALID_FOR_HRES 0x20 +#define CLOCK_SOURCE_USE_FOR_SCHED_CLOCK 0x40 /* simplify initialization of mask field */ #define CLOCKSOURCE_MASK(bits) (cycle_t)((bits) < 64 ? ((1ULL<<(bits))-1) : -1) diff --git a/kernel/sched_clock.c b/kernel/sched_clock.c index e1d16c9..b91190e 100644 --- a/kernel/sched_clock.c +++ b/kernel/sched_clock.c @@ -30,6 +30,7 @@ #include <linux/percpu.h> #include <linux/ktime.h> #include <linux/sched.h> +#include <linux/clocksource.h> /* * Scheduler clock - returns current time in nanosec units. @@ -38,8 +39,9 @@ */ unsigned long long __attribute__((weak)) sched_clock(void) { - return (unsigned long long)(jiffies - INITIAL_JIFFIES) - * (NSEC_PER_SEC / HZ); + struct clocksource *clock = ACCESS_ONCE(sched_clocksource); + + return cyc2ns(clock, clocksource_read(clock)); } static __read_mostly int sched_clock_running; diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index 80189f6..19c72d0 100644 --- a/kernel/time/clocksource.c +++ b/kernel/time/clocksource.c @@ -109,6 +109,7 @@ EXPORT_SYMBOL(timecounter_cyc2time); /* XXX - Would like a better way for initializing curr_clocksource */ extern struct clocksource clocksource_jiffies; +struct clocksource *sched_clocksource = &clocksource_jiffies; /*[Clocksource internal variables]--------- * curr_clocksource: @@ -362,6 +363,9 @@ static struct clocksource *select_clocksource(void) if (next == curr_clocksource) return NULL; + if (next->flags & CLOCK_SOURCE_USE_FOR_SCHED_CLOCK) + sched_clocksource = next; + return next; } @@ -440,7 +444,17 @@ void clocksource_unregister(struct clocksource *cs) list_del(&cs->list); if (clocksource_override == cs) clocksource_override = NULL; + next_clocksource = select_clocksource(); + + /* + * If select_clocksource() fails to find another suitable + * clocksource for sched_clocksource and we are unregistering + * it, switch back to jiffies. + */ + if (sched_clocksource == cs) + sched_clocksource = &clocksource_jiffies; + spin_unlock_irqrestore(&clocksource_lock, flags); } diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c index c3f6c30..727d881 100644 --- a/kernel/time/jiffies.c +++ b/kernel/time/jiffies.c @@ -52,7 +52,7 @@ static cycle_t jiffies_read(struct clocksource *cs) { - return (cycle_t) jiffies; + return (cycle_t) (jiffies - INITIAL_JIFFIES); } struct clocksource clocksource_jiffies = {