* Re: [PATCHv3 3/5] cpuidle: add support for states that affect multiple cpus
From: Rafael J. Wysocki @ 2012-05-04 22:27 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <CAMbhsRRSGypR-N23vXbHSKLc_TPo6PTjQ2-PFicknCqX8tYq9Q@mail.gmail.com>
On Friday, May 04, 2012, Colin Cross wrote:
> On Fri, May 4, 2012 at 4:51 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Friday, May 04, 2012, Colin Cross wrote:
> >> On Thu, May 3, 2012 at 3:14 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > [...]
> >>
> >> >> +/**
> >> >> + * cpuidle_coupled_cpus_waiting - check if all cpus in a coupled set are waiting
> >> >> + * @coupled: the struct coupled that contains the current cpu
> >> >> + *
> >> >> + * Returns true if all cpus coupled to this target state are in the wait loop
> >> >> + */
> >> >> +static inline bool cpuidle_coupled_cpus_waiting(struct cpuidle_coupled *coupled)
> >> >> +{
> >> >> + int alive;
> >> >> + int waiting;
> >> >> +
> >> >> + /*
> >> >> + * Read alive before reading waiting so a booting cpu is not treated as
> >> >> + * idle
> >> >> + */
> >> >
> >> > Well, the comment doesn't really explain much. In particular, why the boot CPU
> >> > could be treated as idle if the reads were in a different order.
> >>
> >> Hm, I think the race condition is on a cpu going down. What about:
> >> Read alive before reading waiting. If waiting is read before alive,
> >> this cpu could see another cpu as waiting just before it goes offline,
> >> between when it the other cpu decrements waiting and when it
> >> decrements alive, which could cause alive == waiting when one cpu is
> >> not waiting.
> >
> > Reading them in this particular order doesn't stop the race, though. I mean,
> > if the hotplug happens just right after you've read alive_count, you still have
> > a wrong value. waiting_count is set independently, it seems, so there's no
> > ordering between the two on the "store" side and the "load" side ordering
> > doesn't matter.
>
> As commented in the hotplug path, hotplug relies on the fact that one
> of the cpus in the cluster is involved in the hotplug of the cpu that
> is changing (this may not be true for multiple clusters, but it is
> easy to fix by IPI-ing to a cpu that is in the same cluster when that
> happens).
That's very fragile and potentially sets a trap for people trying to make
the kernel work on systems with multiple clusters.
> That means that waiting count is always guaranteed to be at
> least 1 less than alive count when alive count changes. All this read
> ordering needs to do is make sure that this cpu doesn't see
> waiting_count == alive_count by reading them in the wrong order.
So, the concern seems to be that if the local CPU reorders the reads
from waiting_count and alive_count and enough time elapses between one
read and the other, the decrementation of waiting_count may happen
between them and then the CPU may use the outdated value for comparison,
right?
Still, though, even if the barrier is there, the modification of
alive_count in the hotplug notifier routine may not happen before
the read from alive_count in cpuidle_coupled_cpus_waiting() is completed.
Isn't that a problem?
> > I would just make the CPU hotplug notifier routine block until
> > cpuidle_enter_state_coupled() is done and the latter return immediately
> > if the CPU hotplug notifier routine is in progress, perhaps falling back
> > to the safe state. Or I would make the CPU hotplug notifier routine
> > disable the "coupled cpuidle" entirely on DOWN_PREPARE and UP_PREPARE
> > and only re-enable it after the hotplug has been completed.
>
> I'll take a look at disabling coupled idle completely during hotplug.
Great, thanks!
> >> >> + alive = atomic_read(&coupled->alive_count);
> >> >> + smp_rmb();
> >> >> + waiting = atomic_read(&coupled->waiting_count);
> >> >
> >> > Have you considered using one atomic variable to accommodate both counters
> >> > such that the upper half contains one counter and the lower half contains
> >> > the other?
> >>
> >> There are 3 counters (alive, waiting, and ready). Do you want me to
> >> squish all of them into a single atomic_t, which would limit to 1023
> >> cpus?
> >
> > No. I'd make sure that cpuidle_enter_state_coupled() did't race with CPU
> > hotplug, so as to make alive_count stable from its standpoint, and I'd
> > put the two remaining counters into one atomic_t variable.
>
> I'll take a look at using a single atomic_t. My initial worry was
> that the increased contention on the shared variable would cause more
> cmpxchg retries, but since waiting_count and ready_count are designed
> to be modified in sequential phases that shouldn't be an issue.
>
[...]
> >> >> + while (!need_resched() && !cpuidle_coupled_cpus_waiting(coupled)) {
> >> >> + entered_state = cpuidle_enter_state(dev, drv,
> >> >> + dev->safe_state_index);
> >> >> +
> >> >> + local_irq_enable();
> >> >> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
> >> >> + cpu_relax();
> >> >
> >> > Hmm. What exactly is this loop supposed to achieve?
> >> This is to ensure that the outstanding wakeups have been processed so
> >> we don't go to idle with an interrupt pending an immediately wake up.
> >
> > I see. Is it actually safe to reenable interrupts at this point, though?
>
> I think so. The normal idle loop will enable interrupts in a similar
> fashion to what happens here. There are two things to worry about: a
> processed interrupt causing work to be scheduled that should bring
> this cpu out of idle, or changing the next timer which would
> invalidate the current requested state. The first is handled by
> checking need_resched() after interrupts are disabled again, the
> second is currently unhandled but does not affect correct operation,
> it just races into a less-than-optimal idle state.
I see.
> >> >> + local_irq_disable();
> >> >
> >> > Anyway, you seem to be calling it twice along with this enabling/disabling of
> >> > interrupts. I'd put that into a separate function and explain its role in a
> >> > kerneldoc comment.
> >>
> >> I left it here to be obvious that I was enabling interrupts in the
> >> idle path, but I can refactor it out if you prefer.
> >
> > Well, you can call the function to make it obvious. :-)
> >
> > Anyway, I think that code duplication is a worse thing than a reasonable
> > amount of non-obviousness, so to speak.
> >
> >> >> + }
> >> >> +
> >> >> + /* give a chance to process any remaining pokes */
> >> >> + local_irq_enable();
> >> >> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
> >> >> + cpu_relax();
> >> >> + local_irq_disable();
> >> >> +
> >> >> + if (need_resched()) {
> >> >> + cpuidle_coupled_set_not_waiting(dev, coupled);
> >> >> + goto out;
> >> >> + }
> >> >> +
> >> >> + /*
> >> >> + * All coupled cpus are probably idle. There is a small chance that
> >> >> + * one of the other cpus just became active. Increment a counter when
> >> >> + * ready, and spin until all coupled cpus have incremented the counter.
> >> >> + * Once a cpu has incremented the counter, it cannot abort idle and must
> >> >> + * spin until either the count has hit alive_count, or another cpu
> >> >> + * leaves idle.
> >> >> + */
> >> >> +
> >> >> + smp_mb__before_atomic_inc();
> >> >> + atomic_inc(&coupled->ready_count);
> >> >> + smp_mb__after_atomic_inc();
> >> >
> >> > It seems that at least one of these barriers is unnecessary ...
> >> The first is to ensure ordering between ready_count and waiting count,
> >
> > Are you afraid that the test against waiting_count from
> > cpuidle_coupled_cpus_waiting() may get reordered after the incrementation
> > of ready_count or is it something else?
>
> Yes, ready_count must not be incremented before waiting_count == alive_count.
Well, control doesn't reach the atomic_inc() statement if this condition
is not satisfied, so I don't see how it can be possibly reordered before
the while () loop without breaking the control flow guarantees.
> >> the second is for ready_count vs. alive_count and requested_state.
> >
> > This one I can understand, but ...
> >
> >> >> + /* alive_count can't change while ready_count > 0 */
> >> >> + alive = atomic_read(&coupled->alive_count);
> >
> > What happens if CPU hotplug happens right here?
>
> According to the comment above that line that can't happen -
> alive_count can't change while ready_count > 0, because that implies
> that all cpus are waiting and none can be in the hotplug path where
> alive_count is changed. Looking at it again that is not entirely
> true, alive_count could change on systems with >2 cpus, but I think it
> can't cause an issue because alive_count would be 2 greater than
> waiting_count before alive_count was changed. Either way, it will be
> fixed by disabling coupled idle during hotplug.
Yup.
> >> >> + while (atomic_read(&coupled->ready_count) != alive) {
> >> >> + /* Check if any other cpus bailed out of idle. */
> >> >> + if (!cpuidle_coupled_cpus_waiting(coupled)) {
> >> >> + atomic_dec(&coupled->ready_count);
> >> >> + smp_mb__after_atomic_dec();
> >
> > And the barrier here? Even if the old value of ready_count leaks into
> > the while () loop after retry, that doesn't seem to matter.
>
> All of these will be academic if ready_count and waiting_count share
> an atomic_t.
> waiting_count must not be decremented by exiting the while loop after
> the retry label until ready_count is decremented here, but that is
> also protected by the barrier in set_not_waiting. One of them could
> be dropped.
>
> >> >> + goto retry;
> >> >> + }
> >> >> +
> >> >> + cpu_relax();
> >> >> + }
> >> >> +
> >> >> + /* all cpus have acked the coupled state */
> >> >> + smp_rmb();
> >> >
> >> > What is the barrier here for?
> >> This protects ready_count vs. requested_state. It is already
> >> implicitly protected by the atomic_inc_return in set_waiting, but I
> >> thought it would be better to protect it explicitly here. I think I
> >> added the smp_mb__after_atomic_inc above later, which makes this one
> >> superflous, so I'll drop it.
> >
> > OK
> >
> >> >> +
> >> >> + next_state = cpuidle_coupled_get_state(dev, coupled);
> >> >> +
> >> >> + entered_state = cpuidle_enter_state(dev, drv, next_state);
> >> >> +
> >> >> + cpuidle_coupled_set_not_waiting(dev, coupled);
> >> >> + atomic_dec(&coupled->ready_count);
> >> >> + smp_mb__after_atomic_dec();
> >> >> +
> >> >> +out:
> >> >> + /*
> >> >> + * Normal cpuidle states are expected to return with irqs enabled.
> >> >> + * That leads to an inefficiency where a cpu receiving an interrupt
> >> >> + * that brings it out of idle will process that interrupt before
> >> >> + * exiting the idle enter function and decrementing ready_count. All
> >> >> + * other cpus will need to spin waiting for the cpu that is processing
> >> >> + * the interrupt. If the driver returns with interrupts disabled,
> >> >> + * all other cpus will loop back into the safe idle state instead of
> >> >> + * spinning, saving power.
> >> >> + *
> >> >> + * Calling local_irq_enable here allows coupled states to return with
> >> >> + * interrupts disabled, but won't cause problems for drivers that
> >> >> + * exit with interrupts enabled.
> >> >> + */
> >> >> + local_irq_enable();
> >> >> +
> >> >> + /*
> >> >> + * Wait until all coupled cpus have exited idle. There is no risk that
> >> >> + * a cpu exits and re-enters the ready state because this cpu has
> >> >> + * already decremented its waiting_count.
> >> >> + */
> >> >> + while (atomic_read(&coupled->ready_count) != 0)
> >> >> + cpu_relax();
> >> >> +
> >> >> + smp_rmb();
> >> >
> >> > And here?
> >>
> >> This was to protect ready_count vs. looping back in and reading
> >> alive_count.
> >
> > Well, I'm lost. :-)
> >
> > You've not modified anything after the previous smp_mb__after_atomic_dec(),
> > so what exactly is the reordering this is supposed to work against?
> >
> > And while we're at it, I'm not quite sure what the things that the previous
> > smp_mb__after_atomic_dec() separates from each other are.
>
> Instead of justifying all of these, let me try the combined atomic_t
> trick and justify the (many fewer) remaining barriers.
OK, cool! :-)
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCHv3 3/5] cpuidle: add support for states that affect multiple cpus
From: Colin Cross @ 2012-05-04 18:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <201205041351.25282.rjw@sisk.pl>
On Fri, May 4, 2012 at 4:51 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Friday, May 04, 2012, Colin Cross wrote:
>> On Thu, May 3, 2012 at 3:14 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> [...]
>>
>> >> +/**
>> >> + * cpuidle_coupled_cpus_waiting - check if all cpus in a coupled set are waiting
>> >> + * @coupled: the struct coupled that contains the current cpu
>> >> + *
>> >> + * Returns true if all cpus coupled to this target state are in the wait loop
>> >> + */
>> >> +static inline bool cpuidle_coupled_cpus_waiting(struct cpuidle_coupled *coupled)
>> >> +{
>> >> + int alive;
>> >> + int waiting;
>> >> +
>> >> + /*
>> >> + * Read alive before reading waiting so a booting cpu is not treated as
>> >> + * idle
>> >> + */
>> >
>> > Well, the comment doesn't really explain much. In particular, why the boot CPU
>> > could be treated as idle if the reads were in a different order.
>>
>> Hm, I think the race condition is on a cpu going down. What about:
>> Read alive before reading waiting. If waiting is read before alive,
>> this cpu could see another cpu as waiting just before it goes offline,
>> between when it the other cpu decrements waiting and when it
>> decrements alive, which could cause alive == waiting when one cpu is
>> not waiting.
>
> Reading them in this particular order doesn't stop the race, though. I mean,
> if the hotplug happens just right after you've read alive_count, you still have
> a wrong value. waiting_count is set independently, it seems, so there's no
> ordering between the two on the "store" side and the "load" side ordering
> doesn't matter.
As commented in the hotplug path, hotplug relies on the fact that one
of the cpus in the cluster is involved in the hotplug of the cpu that
is changing (this may not be true for multiple clusters, but it is
easy to fix by IPI-ing to a cpu that is in the same cluster when that
happens). That means that waiting count is always guaranteed to be at
least 1 less than alive count when alive count changes. All this read
ordering needs to do is make sure that this cpu doesn't see
waiting_count == alive_count by reading them in the wrong order.
> I would just make the CPU hotplug notifier routine block until
> cpuidle_enter_state_coupled() is done and the latter return immediately
> if the CPU hotplug notifier routine is in progress, perhaps falling back
> to the safe state. Or I would make the CPU hotplug notifier routine
> disable the "coupled cpuidle" entirely on DOWN_PREPARE and UP_PREPARE
> and only re-enable it after the hotplug has been completed.
I'll take a look at disabling coupled idle completely during hotplug.
>> >> + alive = atomic_read(&coupled->alive_count);
>> >> + smp_rmb();
>> >> + waiting = atomic_read(&coupled->waiting_count);
>> >
>> > Have you considered using one atomic variable to accommodate both counters
>> > such that the upper half contains one counter and the lower half contains
>> > the other?
>>
>> There are 3 counters (alive, waiting, and ready). Do you want me to
>> squish all of them into a single atomic_t, which would limit to 1023
>> cpus?
>
> No. I'd make sure that cpuidle_enter_state_coupled() did't race with CPU
> hotplug, so as to make alive_count stable from its standpoint, and I'd
> put the two remaining counters into one atomic_t variable.
I'll take a look at using a single atomic_t. My initial worry was
that the increased contention on the shared variable would cause more
cmpxchg retries, but since waiting_count and ready_count are designed
to be modified in sequential phases that shouldn't be an issue.
>> >> +
>> >> + return (waiting == alive);
>> >> +}
>> >> +
>> >> +/**
>> >> + * cpuidle_coupled_get_state - determine the deepest idle state
>> >> + * @dev: struct cpuidle_device for this cpu
>> >> + * @coupled: the struct coupled that contains the current cpu
>> >> + *
>> >> + * Returns the deepest idle state that all coupled cpus can enter
>> >> + */
>> >> +static inline int cpuidle_coupled_get_state(struct cpuidle_device *dev,
>> >> + struct cpuidle_coupled *coupled)
>> >> +{
>> >> + int i;
>> >> + int state = INT_MAX;
>> >> +
>> >> + for_each_cpu_mask(i, coupled->coupled_cpus)
>> >> + if (coupled->requested_state[i] != CPUIDLE_COUPLED_DEAD &&
>> >> + coupled->requested_state[i] < state)
>> >> + state = coupled->requested_state[i];
>> >> +
>> >> + BUG_ON(state >= dev->state_count || state < 0);
>> >
>> > Do you have to crash the kernel here if the assertion doesn't hold? Maybe
>> > you could use WARN_ON() and return error code?
>>
>> If this BUG_ON is hit, there is a race condition somewhere that
>> allowed a cpu out of idle unexpectedly, and there is no way to recover
>> without more race conditions. I don't expect this to ever happen, it
>> is mostly there to detect race conditions during development. Should
>> I drop it completely?
>
> I would just drop it, then, in the final respin of the patch.
>
> [...]
>> >> +{
>> >> + int alive;
>> >> +
>> >> + BUG_ON(coupled->requested_state[dev->cpu] >= 0);
>> >
>> > Would be WARN_ON() + do nothing too dangerous here?
>>
>> If this BUG_ON is hit, then this cpu exited idle without clearing its
>> waiting state, which could cause another cpu to enter the deeper idle
>> state while this cpu is still running. The counters would be out of
>> sync, so it's not easy to recover. Again, this is to detect race
>> conditions during development, but should never happen. Should I drop
>> it?
>
> Just like above.
>
>> >> +
>> >> + coupled->requested_state[dev->cpu] = next_state;
>> >> +
>> >> + /*
>> >> + * If this is the last cpu to enter the waiting state, poke
>> >> + * all the other cpus out of their waiting state so they can
>> >> + * enter a deeper state. This can race with one of the cpus
>> >> + * exiting the waiting state due to an interrupt and
>> >> + * decrementing waiting_count, see comment below.
>> >> + */
>> >> + alive = atomic_read(&coupled->alive_count);
>> >> + if (atomic_inc_return(&coupled->waiting_count) == alive)
>> >> + cpuidle_coupled_poke_others(dev, coupled);
>> >> +}
>> >> +
>> >> +/**
>> >> + * cpuidle_coupled_set_not_waiting - mark this cpu as leaving the wait loop
>> >> + * @dev: struct cpuidle_device for this cpu
>> >> + * @coupled: the struct coupled that contains the current cpu
>> >> + *
>> >> + * Removes the requested idle state for the specified cpuidle device.
>> >> + *
>> >> + * Provides memory ordering around waiting_count.
>> >> + */
>> >> +static void cpuidle_coupled_set_not_waiting(struct cpuidle_device *dev,
>> >> + struct cpuidle_coupled *coupled)
>> >
>> > It looks like dev doesn't have to be passed here, cpu would be enough.
>> >
>> >> +{
>> >> + BUG_ON(coupled->requested_state[dev->cpu] < 0);
>> >
>> > Well, like above?
>> Same as above.
>
> Ditto. :-)
>
>> >> +
>> >> + /*
>> >> + * Decrementing waiting_count can race with incrementing it in
>> >> + * cpuidle_coupled_set_waiting, but that's OK. Worst case, some
>> >> + * cpus will increment ready_count and then spin until they
>> >> + * notice that this cpu has cleared it's requested_state.
>> >> + */
>> >
>> > So it looks like having ready_count and waiting_count in one atomic variable
>> > can spare us this particular race condition.
>> As above, there are 3 counters here, alive, ready, and waiting.
>
> Please refer to my comment about that above.
>
>> >> +
>> >> + smp_mb__before_atomic_dec();
>> >> + atomic_dec(&coupled->waiting_count);
>> >> + smp_mb__after_atomic_dec();
>> >
>> > Do you really need both the before and after barriers here? If so, then why?
>>
>> I believe so, waiting is ordered vs. alive and ready, one barrier is
>> for each. Do you want the answers to these questions here or in the
>> code? I had comments for every barrier use during development, but it
>> made it too hard to follow the flow of the code. I could add a
>> comment describing the ordering requirements instead, but it's still
>> hard to translate that to the required barrier locations.
>
> Well, the barriers should be commented in the code, for the sake of people
> reading it and wanting to learn from it if nothing else.
>
> Wherever we put an SMP barrier directly like this, there should be a good
> reason for that and it should be documented.
>
> [...]
>> >> + */
>> >> +int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
>> >> + struct cpuidle_driver *drv, int next_state)
>> >> +{
>> >> + int entered_state = -1;
>> >> + struct cpuidle_coupled *coupled = dev->coupled;
>> >> + int alive;
>> >> +
>> >> + if (!coupled)
>> >> + return -EINVAL;
>> >> +
>> >> + BUG_ON(atomic_read(&coupled->ready_count));
>> >
>> > Again, I'd do a WARN_ON() and return error code from here (to avoid crashing
>> > the kernel).
>> Same as above, if ready_count is not 0 here then the counters are out
>> of sync and something is about to go horribly wrong, like cutting
>> power to a running cpu.
>
> OK
>
>> >> + cpuidle_coupled_set_waiting(dev, coupled, next_state);
>> >> +
>> >> +retry:
>> >> + /*
>> >> + * Wait for all coupled cpus to be idle, using the deepest state
>> >> + * allowed for a single cpu.
>> >> + */
>> >> + while (!need_resched() && !cpuidle_coupled_cpus_waiting(coupled)) {
>> >> + entered_state = cpuidle_enter_state(dev, drv,
>> >> + dev->safe_state_index);
>> >> +
>> >> + local_irq_enable();
>> >> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
>> >> + cpu_relax();
>> >
>> > Hmm. What exactly is this loop supposed to achieve?
>> This is to ensure that the outstanding wakeups have been processed so
>> we don't go to idle with an interrupt pending an immediately wake up.
>
> I see. Is it actually safe to reenable interrupts at this point, though?
I think so. The normal idle loop will enable interrupts in a similar
fashion to what happens here. There are two things to worry about: a
processed interrupt causing work to be scheduled that should bring
this cpu out of idle, or changing the next timer which would
invalidate the current requested state. The first is handled by
checking need_resched() after interrupts are disabled again, the
second is currently unhandled but does not affect correct operation,
it just races into a less-than-optimal idle state.
>> >> + local_irq_disable();
>> >
>> > Anyway, you seem to be calling it twice along with this enabling/disabling of
>> > interrupts. I'd put that into a separate function and explain its role in a
>> > kerneldoc comment.
>>
>> I left it here to be obvious that I was enabling interrupts in the
>> idle path, but I can refactor it out if you prefer.
>
> Well, you can call the function to make it obvious. :-)
>
> Anyway, I think that code duplication is a worse thing than a reasonable
> amount of non-obviousness, so to speak.
>
>> >> + }
>> >> +
>> >> + /* give a chance to process any remaining pokes */
>> >> + local_irq_enable();
>> >> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
>> >> + cpu_relax();
>> >> + local_irq_disable();
>> >> +
>> >> + if (need_resched()) {
>> >> + cpuidle_coupled_set_not_waiting(dev, coupled);
>> >> + goto out;
>> >> + }
>> >> +
>> >> + /*
>> >> + * All coupled cpus are probably idle. There is a small chance that
>> >> + * one of the other cpus just became active. Increment a counter when
>> >> + * ready, and spin until all coupled cpus have incremented the counter.
>> >> + * Once a cpu has incremented the counter, it cannot abort idle and must
>> >> + * spin until either the count has hit alive_count, or another cpu
>> >> + * leaves idle.
>> >> + */
>> >> +
>> >> + smp_mb__before_atomic_inc();
>> >> + atomic_inc(&coupled->ready_count);
>> >> + smp_mb__after_atomic_inc();
>> >
>> > It seems that at least one of these barriers is unnecessary ...
>> The first is to ensure ordering between ready_count and waiting count,
>
> Are you afraid that the test against waiting_count from
> cpuidle_coupled_cpus_waiting() may get reordered after the incrementation
> of ready_count or is it something else?
Yes, ready_count must not be incremented before waiting_count == alive_count.
>> the second is for ready_count vs. alive_count and requested_state.
>
> This one I can understand, but ...
>
>> >> + /* alive_count can't change while ready_count > 0 */
>> >> + alive = atomic_read(&coupled->alive_count);
>
> What happens if CPU hotplug happens right here?
According to the comment above that line that can't happen -
alive_count can't change while ready_count > 0, because that implies
that all cpus are waiting and none can be in the hotplug path where
alive_count is changed. Looking at it again that is not entirely
true, alive_count could change on systems with >2 cpus, but I think it
can't cause an issue because alive_count would be 2 greater than
waiting_count before alive_count was changed. Either way, it will be
fixed by disabling coupled idle during hotplug.
>> >> + while (atomic_read(&coupled->ready_count) != alive) {
>> >> + /* Check if any other cpus bailed out of idle. */
>> >> + if (!cpuidle_coupled_cpus_waiting(coupled)) {
>> >> + atomic_dec(&coupled->ready_count);
>> >> + smp_mb__after_atomic_dec();
>
> And the barrier here? Even if the old value of ready_count leaks into
> the while () loop after retry, that doesn't seem to matter.
All of these will be academic if ready_count and waiting_count share
an atomic_t.
waiting_count must not be decremented by exiting the while loop after
the retry label until ready_count is decremented here, but that is
also protected by the barrier in set_not_waiting. One of them could
be dropped.
>> >> + goto retry;
>> >> + }
>> >> +
>> >> + cpu_relax();
>> >> + }
>> >> +
>> >> + /* all cpus have acked the coupled state */
>> >> + smp_rmb();
>> >
>> > What is the barrier here for?
>> This protects ready_count vs. requested_state. It is already
>> implicitly protected by the atomic_inc_return in set_waiting, but I
>> thought it would be better to protect it explicitly here. I think I
>> added the smp_mb__after_atomic_inc above later, which makes this one
>> superflous, so I'll drop it.
>
> OK
>
>> >> +
>> >> + next_state = cpuidle_coupled_get_state(dev, coupled);
>> >> +
>> >> + entered_state = cpuidle_enter_state(dev, drv, next_state);
>> >> +
>> >> + cpuidle_coupled_set_not_waiting(dev, coupled);
>> >> + atomic_dec(&coupled->ready_count);
>> >> + smp_mb__after_atomic_dec();
>> >> +
>> >> +out:
>> >> + /*
>> >> + * Normal cpuidle states are expected to return with irqs enabled.
>> >> + * That leads to an inefficiency where a cpu receiving an interrupt
>> >> + * that brings it out of idle will process that interrupt before
>> >> + * exiting the idle enter function and decrementing ready_count. All
>> >> + * other cpus will need to spin waiting for the cpu that is processing
>> >> + * the interrupt. If the driver returns with interrupts disabled,
>> >> + * all other cpus will loop back into the safe idle state instead of
>> >> + * spinning, saving power.
>> >> + *
>> >> + * Calling local_irq_enable here allows coupled states to return with
>> >> + * interrupts disabled, but won't cause problems for drivers that
>> >> + * exit with interrupts enabled.
>> >> + */
>> >> + local_irq_enable();
>> >> +
>> >> + /*
>> >> + * Wait until all coupled cpus have exited idle. There is no risk that
>> >> + * a cpu exits and re-enters the ready state because this cpu has
>> >> + * already decremented its waiting_count.
>> >> + */
>> >> + while (atomic_read(&coupled->ready_count) != 0)
>> >> + cpu_relax();
>> >> +
>> >> + smp_rmb();
>> >
>> > And here?
>>
>> This was to protect ready_count vs. looping back in and reading
>> alive_count.
>
> Well, I'm lost. :-)
>
> You've not modified anything after the previous smp_mb__after_atomic_dec(),
> so what exactly is the reordering this is supposed to work against?
>
> And while we're at it, I'm not quite sure what the things that the previous
> smp_mb__after_atomic_dec() separates from each other are.
Instead of justifying all of these, let me try the combined atomic_t
trick and justify the (many fewer) remaining barriers.
>> There will be plenty of synchronization calls between
>> the two with implicit barriers, but I thought it was better to do it
>> explicitly.
>
> [...]
>> >> +static void cpuidle_coupled_cpu_set_alive(int cpu, bool alive)
>> >> +{
>> >> + struct cpuidle_device *dev;
>> >> + struct cpuidle_coupled *coupled;
>> >> +
>> >> + mutex_lock(&cpuidle_lock);
>> >> +
>> >> + dev = per_cpu(cpuidle_devices, cpu);
>> >> + if (!dev->coupled)
>> >> + goto out;
>> >> +
>> >> + coupled = dev->coupled;
>> >> +
>> >> + /*
>> >> + * waiting_count must be at least 1 less than alive_count, because
>> >> + * this cpu is not waiting. Spin until all cpus have noticed this cpu
>> >> + * is not idle and exited the ready loop before changing alive_count.
>> >> + */
>> >> + while (atomic_read(&coupled->ready_count))
>> >> + cpu_relax();
>> >> +
>> >> + if (alive) {
>> >> + smp_mb__before_atomic_inc();
>> >> + atomic_inc(&coupled->alive_count);
>> >> + smp_mb__after_atomic_inc();
>> >> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
>> >> + } else {
>> >> + smp_mb__before_atomic_dec();
>> >> + atomic_dec(&coupled->alive_count);
>> >> + smp_mb__after_atomic_dec();
>> >> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_DEAD;
>> >
>> > There's too many SMP barriers above, but I'm not quite sure which of them (if
>> > any) are really necessary.
>> The ones before order ready_count vs alive_count, the ones after order
>> alive_count vs. requested_state and future waiting_count increments.
>
> Well, so what are the matching barriers for these?
>
> Rafael
^ permalink raw reply
* Re: Plumbers: PM constraints micro-conf RFP
From: mark gross @ 2012-05-04 14:16 UTC (permalink / raw)
To: mark gross
Cc: Kevin Hilman, Agarwal, Ramesh, paulmck, Praveen Chidambaram,
Amit Kucheria, Antti P Miettinen, John Stultz, linux-pm,
jeen.pihet
In-Reply-To: <20120502143607.GA21640@G62>
On Wed, May 02, 2012 at 07:36:10AM -0700, mark gross wrote:
> This is a Request For Participation in a micro-conference at this years
> Linux plumbers event. For this micro conference to happen we need to
> reach a certain critical mass WRT participants as measured by submitted
> talks associated to Power Management Constraints.
>
> The To: list is populated with folks that I've had interactions with
> over extending pm-qos or constraint based PM over the past year.
>
> If you are working on problems related to constraining the power /
> performance of devices I am inviting your participation and request you
> submit a proposal for presenting your problem space (preferred) and or
> solution to a group of developers looking for a good solution to push
> upstream. The talks will be about 20 min long as I want to get into
> some design and implementation discussions after the requirements
> definition is mostly finished.
>
> I am interested in gathering user mode interface needs as well as kernel
> mode.
>
> From a high level pm-constraints is a generalization of pm-qos to include
> limiting performance as well as its current limiting of device
> throttling.
>
> As performance limiting is typically used for any of the following:
> 1) staying within thermal operational envelopes
> 2) avoiding peak current
> 3) extending battery life in active use cases
>
> I invite anyone working in any of these areas or pm-qos applications to
> participate in this micro-conference.
>
> I will organize the micro-conference into 2 parts:
> 1) problem statements with specific participant examples where
> constraining the performance or throttling is needed.
>
> 2) high level design brain storming.
>
> If the micro-conference happens (i.e. critical mass is reached) any
> interested linux-plumbers attendees is very welcome to participate.
>
> Please send me an off list email if you want me to add you to my mutt
> alias of interested parties I'll use to cc people on emails. Note: must
> of the correspondence will cc linux-pm too.
>
> Please submit a proposal if you are interested in participating in this
> with me. I know a number of people are working in this space for the
> past few years now. I think its a good time to compare notes and at
> least consolidate requirements and use cases. Perhaps we'll even come up
> with a good design to implement in the process.
I forgot to make clear a few things specific to the Plumbers conference.
1) they need proposals by mid may
2) if you want financial assistance to be part of this micro-conf you
need to ask the conference committee and I think I need to recommend you
as an important participant. --- Paul, can you clarify this?
If we don't get a critical mass as determined by the conference
committee we can try again / do more stuff over email. BTW we should be
doing more of anyway.
--mark
> thanks,
> --mark
>
^ permalink raw reply
* Re: [PATCH 1/1] battery: only refresh the sysfs files when pertinant information changes
From: Ralf Jung @ 2012-05-04 13:29 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Matthew Garrett, Rafael J. Wysocki, Jonathan Nieder,
ACPI Devel Maling List, Linux-pm mailing list, Adrian Fita,
Len Brown, Paolo Scarabelli, linux-kernel
In-Reply-To: <1336052907-15084-1-git-send-email-apw@canonical.com>
Hi,
I applied this to 3.4-rc5, and it fixes the issue. Thanks a lot :)
> We only need to regenerate the sysfs files when the capacity units
> change, avoid the update otherwise.
>
> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Tested-by: Ralf Jung <post@ralfj.de>
> ---
> drivers/acpi/battery.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> Based on Matthew's feedback here is a version which optimises
> based on the power_unit field as returned from the battery info.
> Could someone who suffers from this issue please test this out
> and report back. Thanks.
>
> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> index 86933ca..7dd3f9f 100644
> --- a/drivers/acpi/battery.c
> +++ b/drivers/acpi/battery.c
> @@ -643,11 +643,19 @@ static int acpi_battery_update(struct acpi_battery
> *battery)
>
> static void acpi_battery_refresh(struct acpi_battery *battery)
> {
> + int power_unit;
> +
> if (!battery->bat.dev)
> return;
>
> + power_unit = battery->power_unit;
> +
> acpi_battery_get_info(battery);
> - /* The battery may have changed its reporting units. */
> +
> + if (power_unit == battery->power_unit)
> + return;
> +
> + /* The battery has changed its reporting units. */
> sysfs_remove_battery(battery);
> sysfs_add_battery(battery);
> }
Kind regards,
Ralf Jung
^ permalink raw reply
* Re: [PATCHv3 3/5] cpuidle: add support for states that affect multiple cpus
From: Rafael J. Wysocki @ 2012-05-04 11:51 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <CAMbhsRQVH=f+2A_JXg3J2NKvC3dxqPk-QUDcbQ3G9Rv426c3AA@mail.gmail.com>
On Friday, May 04, 2012, Colin Cross wrote:
> On Thu, May 3, 2012 at 3:14 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
[...]
>
> >> +/**
> >> + * cpuidle_coupled_cpus_waiting - check if all cpus in a coupled set are waiting
> >> + * @coupled: the struct coupled that contains the current cpu
> >> + *
> >> + * Returns true if all cpus coupled to this target state are in the wait loop
> >> + */
> >> +static inline bool cpuidle_coupled_cpus_waiting(struct cpuidle_coupled *coupled)
> >> +{
> >> + int alive;
> >> + int waiting;
> >> +
> >> + /*
> >> + * Read alive before reading waiting so a booting cpu is not treated as
> >> + * idle
> >> + */
> >
> > Well, the comment doesn't really explain much. In particular, why the boot CPU
> > could be treated as idle if the reads were in a different order.
>
> Hm, I think the race condition is on a cpu going down. What about:
> Read alive before reading waiting. If waiting is read before alive,
> this cpu could see another cpu as waiting just before it goes offline,
> between when it the other cpu decrements waiting and when it
> decrements alive, which could cause alive == waiting when one cpu is
> not waiting.
Reading them in this particular order doesn't stop the race, though. I mean,
if the hotplug happens just right after you've read alive_count, you still have
a wrong value. waiting_count is set independently, it seems, so there's no
ordering between the two on the "store" side and the "load" side ordering
doesn't matter.
I would just make the CPU hotplug notifier routine block until
cpuidle_enter_state_coupled() is done and the latter return immediately
if the CPU hotplug notifier routine is in progress, perhaps falling back
to the safe state. Or I would make the CPU hotplug notifier routine
disable the "coupled cpuidle" entirely on DOWN_PREPARE and UP_PREPARE
and only re-enable it after the hotplug has been completed.
> >> + alive = atomic_read(&coupled->alive_count);
> >> + smp_rmb();
> >> + waiting = atomic_read(&coupled->waiting_count);
> >
> > Have you considered using one atomic variable to accommodate both counters
> > such that the upper half contains one counter and the lower half contains
> > the other?
>
> There are 3 counters (alive, waiting, and ready). Do you want me to
> squish all of them into a single atomic_t, which would limit to 1023
> cpus?
No. I'd make sure that cpuidle_enter_state_coupled() did't race with CPU
hotplug, so as to make alive_count stable from its standpoint, and I'd
put the two remaining counters into one atomic_t variable.
> >> +
> >> + return (waiting == alive);
> >> +}
> >> +
> >> +/**
> >> + * cpuidle_coupled_get_state - determine the deepest idle state
> >> + * @dev: struct cpuidle_device for this cpu
> >> + * @coupled: the struct coupled that contains the current cpu
> >> + *
> >> + * Returns the deepest idle state that all coupled cpus can enter
> >> + */
> >> +static inline int cpuidle_coupled_get_state(struct cpuidle_device *dev,
> >> + struct cpuidle_coupled *coupled)
> >> +{
> >> + int i;
> >> + int state = INT_MAX;
> >> +
> >> + for_each_cpu_mask(i, coupled->coupled_cpus)
> >> + if (coupled->requested_state[i] != CPUIDLE_COUPLED_DEAD &&
> >> + coupled->requested_state[i] < state)
> >> + state = coupled->requested_state[i];
> >> +
> >> + BUG_ON(state >= dev->state_count || state < 0);
> >
> > Do you have to crash the kernel here if the assertion doesn't hold? Maybe
> > you could use WARN_ON() and return error code?
>
> If this BUG_ON is hit, there is a race condition somewhere that
> allowed a cpu out of idle unexpectedly, and there is no way to recover
> without more race conditions. I don't expect this to ever happen, it
> is mostly there to detect race conditions during development. Should
> I drop it completely?
I would just drop it, then, in the final respin of the patch.
[...]
> >> +{
> >> + int alive;
> >> +
> >> + BUG_ON(coupled->requested_state[dev->cpu] >= 0);
> >
> > Would be WARN_ON() + do nothing too dangerous here?
>
> If this BUG_ON is hit, then this cpu exited idle without clearing its
> waiting state, which could cause another cpu to enter the deeper idle
> state while this cpu is still running. The counters would be out of
> sync, so it's not easy to recover. Again, this is to detect race
> conditions during development, but should never happen. Should I drop
> it?
Just like above.
> >> +
> >> + coupled->requested_state[dev->cpu] = next_state;
> >> +
> >> + /*
> >> + * If this is the last cpu to enter the waiting state, poke
> >> + * all the other cpus out of their waiting state so they can
> >> + * enter a deeper state. This can race with one of the cpus
> >> + * exiting the waiting state due to an interrupt and
> >> + * decrementing waiting_count, see comment below.
> >> + */
> >> + alive = atomic_read(&coupled->alive_count);
> >> + if (atomic_inc_return(&coupled->waiting_count) == alive)
> >> + cpuidle_coupled_poke_others(dev, coupled);
> >> +}
> >> +
> >> +/**
> >> + * cpuidle_coupled_set_not_waiting - mark this cpu as leaving the wait loop
> >> + * @dev: struct cpuidle_device for this cpu
> >> + * @coupled: the struct coupled that contains the current cpu
> >> + *
> >> + * Removes the requested idle state for the specified cpuidle device.
> >> + *
> >> + * Provides memory ordering around waiting_count.
> >> + */
> >> +static void cpuidle_coupled_set_not_waiting(struct cpuidle_device *dev,
> >> + struct cpuidle_coupled *coupled)
> >
> > It looks like dev doesn't have to be passed here, cpu would be enough.
> >
> >> +{
> >> + BUG_ON(coupled->requested_state[dev->cpu] < 0);
> >
> > Well, like above?
> Same as above.
Ditto. :-)
> >> +
> >> + /*
> >> + * Decrementing waiting_count can race with incrementing it in
> >> + * cpuidle_coupled_set_waiting, but that's OK. Worst case, some
> >> + * cpus will increment ready_count and then spin until they
> >> + * notice that this cpu has cleared it's requested_state.
> >> + */
> >
> > So it looks like having ready_count and waiting_count in one atomic variable
> > can spare us this particular race condition.
> As above, there are 3 counters here, alive, ready, and waiting.
Please refer to my comment about that above.
> >> +
> >> + smp_mb__before_atomic_dec();
> >> + atomic_dec(&coupled->waiting_count);
> >> + smp_mb__after_atomic_dec();
> >
> > Do you really need both the before and after barriers here? If so, then why?
>
> I believe so, waiting is ordered vs. alive and ready, one barrier is
> for each. Do you want the answers to these questions here or in the
> code? I had comments for every barrier use during development, but it
> made it too hard to follow the flow of the code. I could add a
> comment describing the ordering requirements instead, but it's still
> hard to translate that to the required barrier locations.
Well, the barriers should be commented in the code, for the sake of people
reading it and wanting to learn from it if nothing else.
Wherever we put an SMP barrier directly like this, there should be a good
reason for that and it should be documented.
[...]
> >> + */
> >> +int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
> >> + struct cpuidle_driver *drv, int next_state)
> >> +{
> >> + int entered_state = -1;
> >> + struct cpuidle_coupled *coupled = dev->coupled;
> >> + int alive;
> >> +
> >> + if (!coupled)
> >> + return -EINVAL;
> >> +
> >> + BUG_ON(atomic_read(&coupled->ready_count));
> >
> > Again, I'd do a WARN_ON() and return error code from here (to avoid crashing
> > the kernel).
> Same as above, if ready_count is not 0 here then the counters are out
> of sync and something is about to go horribly wrong, like cutting
> power to a running cpu.
OK
> >> + cpuidle_coupled_set_waiting(dev, coupled, next_state);
> >> +
> >> +retry:
> >> + /*
> >> + * Wait for all coupled cpus to be idle, using the deepest state
> >> + * allowed for a single cpu.
> >> + */
> >> + while (!need_resched() && !cpuidle_coupled_cpus_waiting(coupled)) {
> >> + entered_state = cpuidle_enter_state(dev, drv,
> >> + dev->safe_state_index);
> >> +
> >> + local_irq_enable();
> >> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
> >> + cpu_relax();
> >
> > Hmm. What exactly is this loop supposed to achieve?
> This is to ensure that the outstanding wakeups have been processed so
> we don't go to idle with an interrupt pending an immediately wake up.
I see. Is it actually safe to reenable interrupts at this point, though?
> >> + local_irq_disable();
> >
> > Anyway, you seem to be calling it twice along with this enabling/disabling of
> > interrupts. I'd put that into a separate function and explain its role in a
> > kerneldoc comment.
>
> I left it here to be obvious that I was enabling interrupts in the
> idle path, but I can refactor it out if you prefer.
Well, you can call the function to make it obvious. :-)
Anyway, I think that code duplication is a worse thing than a reasonable
amount of non-obviousness, so to speak.
> >> + }
> >> +
> >> + /* give a chance to process any remaining pokes */
> >> + local_irq_enable();
> >> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
> >> + cpu_relax();
> >> + local_irq_disable();
> >> +
> >> + if (need_resched()) {
> >> + cpuidle_coupled_set_not_waiting(dev, coupled);
> >> + goto out;
> >> + }
> >> +
> >> + /*
> >> + * All coupled cpus are probably idle. There is a small chance that
> >> + * one of the other cpus just became active. Increment a counter when
> >> + * ready, and spin until all coupled cpus have incremented the counter.
> >> + * Once a cpu has incremented the counter, it cannot abort idle and must
> >> + * spin until either the count has hit alive_count, or another cpu
> >> + * leaves idle.
> >> + */
> >> +
> >> + smp_mb__before_atomic_inc();
> >> + atomic_inc(&coupled->ready_count);
> >> + smp_mb__after_atomic_inc();
> >
> > It seems that at least one of these barriers is unnecessary ...
> The first is to ensure ordering between ready_count and waiting count,
Are you afraid that the test against waiting_count from
cpuidle_coupled_cpus_waiting() may get reordered after the incrementation
of ready_count or is it something else?
> the second is for ready_count vs. alive_count and requested_state.
This one I can understand, but ...
> >> + /* alive_count can't change while ready_count > 0 */
> >> + alive = atomic_read(&coupled->alive_count);
What happens if CPU hotplug happens right here?
> >> + while (atomic_read(&coupled->ready_count) != alive) {
> >> + /* Check if any other cpus bailed out of idle. */
> >> + if (!cpuidle_coupled_cpus_waiting(coupled)) {
> >> + atomic_dec(&coupled->ready_count);
> >> + smp_mb__after_atomic_dec();
And the barrier here? Even if the old value of ready_count leaks into
the while () loop after retry, that doesn't seem to matter.
> >> + goto retry;
> >> + }
> >> +
> >> + cpu_relax();
> >> + }
> >> +
> >> + /* all cpus have acked the coupled state */
> >> + smp_rmb();
> >
> > What is the barrier here for?
> This protects ready_count vs. requested_state. It is already
> implicitly protected by the atomic_inc_return in set_waiting, but I
> thought it would be better to protect it explicitly here. I think I
> added the smp_mb__after_atomic_inc above later, which makes this one
> superflous, so I'll drop it.
OK
> >> +
> >> + next_state = cpuidle_coupled_get_state(dev, coupled);
> >> +
> >> + entered_state = cpuidle_enter_state(dev, drv, next_state);
> >> +
> >> + cpuidle_coupled_set_not_waiting(dev, coupled);
> >> + atomic_dec(&coupled->ready_count);
> >> + smp_mb__after_atomic_dec();
> >> +
> >> +out:
> >> + /*
> >> + * Normal cpuidle states are expected to return with irqs enabled.
> >> + * That leads to an inefficiency where a cpu receiving an interrupt
> >> + * that brings it out of idle will process that interrupt before
> >> + * exiting the idle enter function and decrementing ready_count. All
> >> + * other cpus will need to spin waiting for the cpu that is processing
> >> + * the interrupt. If the driver returns with interrupts disabled,
> >> + * all other cpus will loop back into the safe idle state instead of
> >> + * spinning, saving power.
> >> + *
> >> + * Calling local_irq_enable here allows coupled states to return with
> >> + * interrupts disabled, but won't cause problems for drivers that
> >> + * exit with interrupts enabled.
> >> + */
> >> + local_irq_enable();
> >> +
> >> + /*
> >> + * Wait until all coupled cpus have exited idle. There is no risk that
> >> + * a cpu exits and re-enters the ready state because this cpu has
> >> + * already decremented its waiting_count.
> >> + */
> >> + while (atomic_read(&coupled->ready_count) != 0)
> >> + cpu_relax();
> >> +
> >> + smp_rmb();
> >
> > And here?
>
> This was to protect ready_count vs. looping back in and reading
> alive_count.
Well, I'm lost. :-)
You've not modified anything after the previous smp_mb__after_atomic_dec(),
so what exactly is the reordering this is supposed to work against?
And while we're at it, I'm not quite sure what the things that the previous
smp_mb__after_atomic_dec() separates from each other are.
> There will be plenty of synchronization calls between
> the two with implicit barriers, but I thought it was better to do it
> explicitly.
[...]
> >> +static void cpuidle_coupled_cpu_set_alive(int cpu, bool alive)
> >> +{
> >> + struct cpuidle_device *dev;
> >> + struct cpuidle_coupled *coupled;
> >> +
> >> + mutex_lock(&cpuidle_lock);
> >> +
> >> + dev = per_cpu(cpuidle_devices, cpu);
> >> + if (!dev->coupled)
> >> + goto out;
> >> +
> >> + coupled = dev->coupled;
> >> +
> >> + /*
> >> + * waiting_count must be at least 1 less than alive_count, because
> >> + * this cpu is not waiting. Spin until all cpus have noticed this cpu
> >> + * is not idle and exited the ready loop before changing alive_count.
> >> + */
> >> + while (atomic_read(&coupled->ready_count))
> >> + cpu_relax();
> >> +
> >> + if (alive) {
> >> + smp_mb__before_atomic_inc();
> >> + atomic_inc(&coupled->alive_count);
> >> + smp_mb__after_atomic_inc();
> >> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
> >> + } else {
> >> + smp_mb__before_atomic_dec();
> >> + atomic_dec(&coupled->alive_count);
> >> + smp_mb__after_atomic_dec();
> >> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_DEAD;
> >
> > There's too many SMP barriers above, but I'm not quite sure which of them (if
> > any) are really necessary.
> The ones before order ready_count vs alive_count, the ones after order
> alive_count vs. requested_state and future waiting_count increments.
Well, so what are the matching barriers for these?
Rafael
^ permalink raw reply
* Re: [PATCH V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
From: J, KEERTHY @ 2012-05-04 10:11 UTC (permalink / raw)
To: AnilKumar, Chimata
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Hilman, Kevin, rjw@sisk.pl, linux-kernel@vger.kernel.org,
linux-pm@lists.linux-foundation.org, Pihet-XID, Jean
In-Reply-To: <331ABD5ECB02734CA317220B2BBEABC13E9B1AA2@DBDE01.ent.ti.com>
Hi AnilKumar,
Thanks for reviewing.
On Fri, May 4, 2012 at 2:00 PM, AnilKumar, Chimata <anilkumar@ti.com> wrote:
> On Thu, Apr 26, 2012 at 23:10:35, J, KEERTHY wrote:
>> From: Jean Pihet <j-pihet@ti.com>
>>
>> Change the name field value to better reflect the smartreflex
>> integration in the system.
>>
>> Signed-off-by: Jean Pihet <j-pihet@ti.com>
>> Signed-off-by: J Keerthy <j-keerthy@ti.com>
>> ---
>> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 ++++----
>> arch/arm/mach-omap2/smartreflex.c | 2 +-
>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> index 144d118..15907b0 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
>> @@ -1324,7 +1324,7 @@ static struct omap_hwmod_irq_info omap3_smartreflex_mpu_irqs[] = {
>> };
>>
>> static struct omap_hwmod omap34xx_sr1_hwmod = {
>> - .name = "sr1",
>> + .name = "smartreflex_mpu_iva",
>> .class = &omap34xx_smartreflex_hwmod_class,
>> .main_clk = "sr1_fck",
>> .prcm = {
>> @@ -1342,7 +1342,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
>> };
>>
>> static struct omap_hwmod omap36xx_sr1_hwmod = {
>> - .name = "sr1",
>> + .name = "smartreflex_mpu_iva",
>> .class = &omap36xx_smartreflex_hwmod_class,
>> .main_clk = "sr1_fck",
>> .prcm = {
>> @@ -1369,7 +1369,7 @@ static struct omap_hwmod_irq_info omap3_smartreflex_core_irqs[] = {
>> };
>>
>> static struct omap_hwmod omap34xx_sr2_hwmod = {
>> - .name = "sr2",
>> + .name = "smartreflex_core",
>> .class = &omap34xx_smartreflex_hwmod_class,
>> .main_clk = "sr2_fck",
>> .prcm = {
>> @@ -1387,7 +1387,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
>> };
>>
>> static struct omap_hwmod omap36xx_sr2_hwmod = {
>> - .name = "sr2",
>> + .name = "smartreflex_core",
>> .class = &omap36xx_smartreflex_hwmod_class,
>> .main_clk = "sr2_fck",
>> .prcm = {
>> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
>> index 2edd1e2..d859277 100644
>> --- a/arch/arm/mach-omap2/smartreflex.c
>> +++ b/arch/arm/mach-omap2/smartreflex.c
>> @@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
>> sr->err_weight = OMAP3430_SR_ERRWEIGHT;
>> sr->err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
>> sr->accum_data = OMAP3430_SR_ACCUMDATA;
>> - if (!(strcmp(sr->name, "sr1"))) {
>> + if (!(strcmp(sr->name, "smartreflex_mpu_iva"))) {
>
> What if voltage rail is different for mpu and iva? I have seen some devices
> supports SmartReflex have different voltage rails for mpu and iva.
>
I get the point. OMAP3 iva and mpu have a common rail. OMAP4 onwards
even we have different rails for mpu and iva. I will enhance the checks here.
> Regards
> AnilKumar
--
Regards and Thanks,
Keerthy
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Lorenzo Pieralisi @ 2012-05-04 10:04 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kevin Hilman, Len Brown, Russell King, Kay Sievers,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, Amit Kucheria,
Colin Cross, linux-pm@lists.linux-foundation.org,
Arjan van de Ven, Arnd Bergmann,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <201205032200.01823.rjw@sisk.pl>
On Thu, May 03, 2012 at 09:00:01PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, May 01, 2012, Colin Cross wrote:
> > On Mon, Apr 30, 2012 at 2:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > On Monday, April 30, 2012, Colin Cross wrote:
> > >> On Mon, Apr 30, 2012 at 2:25 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
[...]
> Having considered this for a while I think that it may be more straightforward
> to avoid waking up the already idled cores.
>
> For instance, say we have 4 CPU cores in a cluster (package) such that each
> core has its own idle state (call it C1) and there is a multicore idle state
> entered by turning off the entire cluster (call this state C-multi). One of
> the possible ways to handle this seems to be to use an identical table of
> C-states for each core containing the C1 entry and a kind of fake entry called
> (for example) C4 with the time characteristics of C-multi and a special
> .enter() callback. That callback will prepare the core it is called for to
> enter C-multi, but instead of simply turning off the whole package it will
> decrement a counter. If the counte happens to be 0 at this point, the
> package will be turned off. Otherwise, the core will be put into the idle
> state corresponding to C1, but it will be ready for entering C-multi at
> any time. The counter will be incremented on exiting the C4 "state".
>
> It looks like this should work without modifying the cpuidle core, but
> the drawback here is that the cpuidle core doesn't know how much time
> spend in C4 is really in C1 and how much of it is in C-multi, so the
> statistics reported by it won't reflect the real energy usage.
This is exactly what has been done in some ARM platforms with per-CPU power
rails ("C1" means shutdown here) and that are completely symmetric (ie every
CPU can trigger cluster shutdown); a "C4" multi-CPU state with target_residency
equivalent to the cluster shutdown implied power break-even point.
There are two issues with this approach. One you already mentioned it.
Second is that CPUs go idle at different times. Hence, by the time the last
CPU calls C4.enter() other CPUs in the package might already have a timer
that is about to expire. If we start cluster shutdown we are wasting power
(eg caches write-back to DDR) for nothing.
Colin and Santosh mentioned it already, we have to peek at the next event for
all CPUs in the package (or peek the broadcast global timer if CPUs rely
on it) and make a decision accordingly.
Lorenzo
^ permalink raw reply
* RE: [PATCH V3 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
From: AnilKumar, Chimata @ 2012-05-04 9:12 UTC (permalink / raw)
To: J, KEERTHY, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Hilman, Kevin, rjw@sisk.pl,
linux-kernel@vger.kernel.org, linux-pm@lists.linux-foundation.org
Cc: Pihet-XID, Jean
In-Reply-To: <1335462041-4949-6-git-send-email-j-keerthy@ti.com>
On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
> From: Jean Pihet <j-pihet@ti.com>
>
> Now that omap_test_timeout is only accessible from mach-omap2/,
> introduce a similar function for SR.
>
> This change makes the SmartReflex implementation ready for the move
> to drivers/.
>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
> Signed-off-by: J Keerthy <j-keerthy@ti.com>
> ---
> arch/arm/mach-omap2/smartreflex.c | 12 ++++++------
> include/linux/power/smartreflex.h | 23 ++++++++++++++++++++++-
> 2 files changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index d859277..acef08d 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -289,9 +289,9 @@ static void sr_v1_disable(struct omap_sr *sr)
> * Wait for SR to be disabled.
> * wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
> */
> - omap_test_timeout((sr_read_reg(sr, ERRCONFIG_V1) &
> - ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
> - timeout);
> + sr_test_cond_timeout((sr_read_reg(sr, ERRCONFIG_V1) &
> + ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
> + timeout);
>
> if (timeout >= SR_DISABLE_TIMEOUT)
> dev_warn(&sr->pdev->dev, "%s: Smartreflex disable timedout\n",
> @@ -334,9 +334,9 @@ static void sr_v2_disable(struct omap_sr *sr)
> * Wait for SR to be disabled.
> * wait until IRQSTATUS.MCUDISACKINTST = 1. Typical latency is 1us.
> */
> - omap_test_timeout((sr_read_reg(sr, IRQSTATUS) &
> - IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
> - timeout);
> + sr_test_cond_timeout((sr_read_reg(sr, IRQSTATUS) &
> + IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
> + timeout);
>
> if (timeout >= SR_DISABLE_TIMEOUT)
> dev_warn(&sr->pdev->dev, "%s: Smartreflex disable timedout\n",
> diff --git a/include/linux/power/smartreflex.h b/include/linux/power/smartreflex.h
> index 884eaee..78b795e 100644
> --- a/include/linux/power/smartreflex.h
> +++ b/include/linux/power/smartreflex.h
> @@ -22,7 +22,7 @@
>
> #include <linux/types.h>
> #include <linux/platform_device.h>
> -
> +#include <linux/delay.h>
> #include <plat/voltage.h>
>
> /*
> @@ -168,6 +168,27 @@ struct omap_sr {
> };
>
> /**
> + * test_cond_timeout - busy-loop, testing a condition
> + * @cond: condition to test until it evaluates to true
> + * @timeout: maximum number of microseconds in the timeout
> + * @index: loop index (integer)
> + *
> + * Loop waiting for @cond to become true or until at least @timeout
> + * microseconds have passed. To use, define some integer @index in the
> + * calling code. After running, if @index == @timeout, then the loop has
> + * timed out.
> + *
> + * Copied from omap_test_timeout */
> +#define sr_test_cond_timeout(cond, timeout, index) \
> +({ \
> + for (index = 0; index < timeout; index++) { \
> + if (cond) \
> + break; \
> + udelay(1); \
> + } \
> +})
I think we can use time_after()/time_before() APIs for timeout and cpu_relax() for
tight loops instead of udelay().
Regards
AnilKumar
^ permalink raw reply
* RE: [PATCH V3 04/10] ARM: OMAP3: hwmod: rename the smartreflex entries
From: AnilKumar, Chimata @ 2012-05-04 8:30 UTC (permalink / raw)
To: J, KEERTHY, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Hilman, Kevin, rjw@sisk.pl,
linux-kernel@vger.kernel.org, linux-pm@lists.linux-foundation.org
Cc: Pihet-XID, Jean
In-Reply-To: <1335462041-4949-5-git-send-email-j-keerthy@ti.com>
On Thu, Apr 26, 2012 at 23:10:35, J, KEERTHY wrote:
> From: Jean Pihet <j-pihet@ti.com>
>
> Change the name field value to better reflect the smartreflex
> integration in the system.
>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
> Signed-off-by: J Keerthy <j-keerthy@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8 ++++----
> arch/arm/mach-omap2/smartreflex.c | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index 144d118..15907b0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -1324,7 +1324,7 @@ static struct omap_hwmod_irq_info omap3_smartreflex_mpu_irqs[] = {
> };
>
> static struct omap_hwmod omap34xx_sr1_hwmod = {
> - .name = "sr1",
> + .name = "smartreflex_mpu_iva",
> .class = &omap34xx_smartreflex_hwmod_class,
> .main_clk = "sr1_fck",
> .prcm = {
> @@ -1342,7 +1342,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
> };
>
> static struct omap_hwmod omap36xx_sr1_hwmod = {
> - .name = "sr1",
> + .name = "smartreflex_mpu_iva",
> .class = &omap36xx_smartreflex_hwmod_class,
> .main_clk = "sr1_fck",
> .prcm = {
> @@ -1369,7 +1369,7 @@ static struct omap_hwmod_irq_info omap3_smartreflex_core_irqs[] = {
> };
>
> static struct omap_hwmod omap34xx_sr2_hwmod = {
> - .name = "sr2",
> + .name = "smartreflex_core",
> .class = &omap34xx_smartreflex_hwmod_class,
> .main_clk = "sr2_fck",
> .prcm = {
> @@ -1387,7 +1387,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
> };
>
> static struct omap_hwmod omap36xx_sr2_hwmod = {
> - .name = "sr2",
> + .name = "smartreflex_core",
> .class = &omap36xx_smartreflex_hwmod_class,
> .main_clk = "sr2_fck",
> .prcm = {
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index 2edd1e2..d859277 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -183,7 +183,7 @@ static void sr_set_regfields(struct omap_sr *sr)
> sr->err_weight = OMAP3430_SR_ERRWEIGHT;
> sr->err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
> sr->accum_data = OMAP3430_SR_ACCUMDATA;
> - if (!(strcmp(sr->name, "sr1"))) {
> + if (!(strcmp(sr->name, "smartreflex_mpu_iva"))) {
What if voltage rail is different for mpu and iva? I have seen some devices
supports SmartReflex have different voltage rails for mpu and iva.
Regards
AnilKumar
^ permalink raw reply
* RE: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: AnilKumar, Chimata @ 2012-05-04 8:21 UTC (permalink / raw)
To: Hilman, Kevin, Mark Brown
Cc: J, KEERTHY, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, rjw@sisk.pl,
linux-kernel@vger.kernel.org, linux-pm@lists.linux-foundation.org,
Pihet-XID, Jean
In-Reply-To: <87397o3n4y.fsf@ti.com>
On Sat, Apr 28, 2012 at 02:31:17, Hilman, Kevin wrote:
> Hi Mark,
>
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>
> > On Fri, Apr 27, 2012 at 11:09:10AM +0530, J, KEERTHY wrote:
> >
> >> Devfreq and cpufreq are related to dynamic frequency/voltage switching between
> >> pre defined Operating Performance Points or the OPPs. Every OPP being
> >> a voltage/frequency pair. Smartreflex is a different
> >> power management technique.
> >
> > But presumably these things should integrate somehow - for example,
> > should devfreq and cpufreq be providing inputs into what AVS is doing,
> > and if so how?
>
> The way it is currently designed, cpufreq/devfreq/regulator layers don't
> need to know about AVS.
>
> The higher-level layers only know about the "nominal" voltage. AVS
> hardware does automatic, adaptive, micro-adjustments around that nominal
> voltage, and these micro-adjustments are managed by the AVS hardware
> sending commands to the PMIC. (specifically, on OMAP, the AVS sensors
> provide inputs to the voltage processor (VP) which provide inputs to the
> voltage controller (VC) which sends commands to the PMIC[1].)
>
> The driver proposed here is primarily for initializing the various
> parameters/sensitivity/etc. of the AVS hardware, but the actual voltage
> adjustments are done in hardware by VC/VP.
>
> The only thing the higher-level layers might potentially need to do to
> enable/disable AVS around transitions (e.g. when changing OPP, AVS is
> disabled before changing OPP and only re-enabled when the new nominal
> voltage has been acheived.)
>
> On OMAP, we handle this inside the OMAP-specific voltage layer which is
> called by the regulator framework, so even the regulators do not need
> any knowledge of AVS.
Kevin,
I want to point out some cases of SR implementation where this may not
be true.
Devices like DM8168, DM8148 and AM335X use Class 2B implementation of SR.
Under this, SR module issues an interrupt to ARM when there is a need to
change the voltage based on temperature changes, ageing etc.
Once the interrupt arrives, kernel needs to adjust voltage using regulator API.
The voltage change is a micro adjustment as in other SR classes.
The SR class 2B implementation on these devices does not exist in mainline.
I can point to some public repositories if you are interested in taking a look at
the current code.
Implementation of this SR method is must on at least the DM8168 device and
I know some customers who are using it on their production systems.
Regards
AnilKumar
^ permalink raw reply
* Re: [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)
From: J, KEERTHY @ 2012-05-04 5:05 UTC (permalink / raw)
To: Kevin Hilman
Cc: Mark Brown, linux-omap, linux-arm-kernel, rjw, linux-kernel,
linux-pm, j-pihet, durgadoss.r
In-Reply-To: <CAJ6a13ZBwZn20ObD2hy=xna8oFoKtdczYNxyWACJZoJkhKhsUQ@mail.gmail.com>
On Wed, May 2, 2012 at 10:34 AM, J, KEERTHY <j-keerthy@ti.com> wrote:
> On Tue, May 1, 2012 at 3:21 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>>
>>> On Fri, Apr 27, 2012 at 02:01:17PM -0700, Kevin Hilman wrote:
>>>> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
>>>
>>>> > But presumably these things should integrate somehow - for example,
>>>> > should devfreq and cpufreq be providing inputs into what AVS is doing,
>>>> > and if so how?
>>>
>>>> The way it is currently designed, cpufreq/devfreq/regulator layers don't
>>>> need to know about AVS.
>>>
>>> Yes, and that was a part of my concern, but see below.
>>>
>>>> The higher-level layers only know about the "nominal" voltage. AVS
>>>> hardware does automatic, adaptive, micro-adjustments around that nominal
>>>> voltage, and these micro-adjustments are managed by the AVS hardware
>>>> sending commands to the PMIC. (specifically, on OMAP, the AVS sensors
>>>> provide inputs to the voltage processor (VP) which provide inputs to the
>>>> voltage controller (VC) which sends commands to the PMIC[1].)
>>>
>>> Right, that's what I'd understood it to be.
>>>
>>>> The driver proposed here is primarily for initializing the various
>>>> parameters/sensitivity/etc. of the AVS hardware, but the actual voltage
>>>> adjustments are done in hardware by VC/VP.
>>>
>>> It's not just a driver, though - it's also creating this power/avs
>>> thing, though now I look at the code rather than just its shape there's
>>> not actually an abstraction being added here, it's mostly just straight
>>> code motion of the arch/arm code that's there already. The changelog
>>> and the shape of the code make it sound like this is intended to be
>>> somewhat generic when really it's providing some OMAP specific tuning
>>> for the device which is much less of a concern.
>>>
>>> I guess for now it's probably OK to just clarify in the documentation
>>> and say that whoever adds the second driver has to work on making this
>>> generic :)
>>
>> Agreed.
>>
>> In a different thread (which I can't seem to find now) we discussed this
>> as well, so it just sounds like the changelog should clarify this a bit
>> better.
>
> Kevin/Mark,
>
> Thanks for the feedback. I will add more documentation
> to clarify this aspect. Please let me know if there are any more
> things to be taken care of in this patch set.
Hello Kevin,
A gentle ping on this series. Any comments on this?
>
>>
>> Kevin
>>
>>> This does also sound rather like it's in a similar area to the current
>>> management work which Durgadoss R (CCed) was working on, though with a
>>> slightly different application and in the OMAP case it's pretty much all
>>> hidden in the external processor.
>>
>
>
>
> --
> Regards and Thanks,
> Keerthy
--
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 3/5] cpuidle: add support for states that affect multiple cpus
From: Colin Cross @ 2012-05-03 23:09 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <201205040014.05880.rjw@sisk.pl>
On Thu, May 3, 2012 at 3:14 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday, April 30, 2012, Colin Cross wrote:
<snip>
>> +/**
>> + * DOC: Coupled cpuidle states
>> + *
>> + * On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
>> + * cpus cannot be independently powered down, either due to
>> + * sequencing restrictions (on Tegra 2, cpu 0 must be the last to
>> + * power down), or due to HW bugs (on OMAP4460, a cpu powering up
>> + * will corrupt the gic state unless the other cpu runs a work
>> + * around). Each cpu has a power state that it can enter without
>> + * coordinating with the other cpu (usually Wait For Interrupt, or
>> + * WFI), and one or more "coupled" power states that affect blocks
>> + * shared between the cpus (L2 cache, interrupt controller, and
>> + * sometimes the whole SoC). Entering a coupled power state must
>> + * be tightly controlled on both cpus.
>> + *
>> + * The easiest solution to implementing coupled cpu power states is
>> + * to hotplug all but one cpu whenever possible, usually using a
>> + * cpufreq governor that looks at cpu load to determine when to
>> + * enable the secondary cpus. This causes problems, as hotplug is an
>> + * expensive operation, so the number of hotplug transitions must be
>> + * minimized, leading to very slow response to loads, often on the
>> + * order of seconds.
>
> I'd drop the above paragraph entirely. It doesn't say much about what's in
> the file and refers to an obviously suboptimal approach.
Sure.
<snip>
>> +/*
>> + * The cpuidle_coupled_poked_mask masked is used to avoid calling
>
> s/masked/mask/ perhaps?
Sure.
<snip>
>> +/**
>> + * cpuidle_coupled_cpus_waiting - check if all cpus in a coupled set are waiting
>> + * @coupled: the struct coupled that contains the current cpu
>> + *
>> + * Returns true if all cpus coupled to this target state are in the wait loop
>> + */
>> +static inline bool cpuidle_coupled_cpus_waiting(struct cpuidle_coupled *coupled)
>> +{
>> + int alive;
>> + int waiting;
>> +
>> + /*
>> + * Read alive before reading waiting so a booting cpu is not treated as
>> + * idle
>> + */
>
> Well, the comment doesn't really explain much. In particular, why the boot CPU
> could be treated as idle if the reads were in a different order.
Hm, I think the race condition is on a cpu going down. What about:
Read alive before reading waiting. If waiting is read before alive,
this cpu could see another cpu as waiting just before it goes offline,
between when it the other cpu decrements waiting and when it
decrements alive, which could cause alive == waiting when one cpu is
not waiting.
>> + alive = atomic_read(&coupled->alive_count);
>> + smp_rmb();
>> + waiting = atomic_read(&coupled->waiting_count);
>
> Have you considered using one atomic variable to accommodate both counters
> such that the upper half contains one counter and the lower half contains
> the other?
There are 3 counters (alive, waiting, and ready). Do you want me to
squish all of them into a single atomic_t, which would limit to 1023
cpus?
>> +
>> + return (waiting == alive);
>> +}
>> +
>> +/**
>> + * cpuidle_coupled_get_state - determine the deepest idle state
>> + * @dev: struct cpuidle_device for this cpu
>> + * @coupled: the struct coupled that contains the current cpu
>> + *
>> + * Returns the deepest idle state that all coupled cpus can enter
>> + */
>> +static inline int cpuidle_coupled_get_state(struct cpuidle_device *dev,
>> + struct cpuidle_coupled *coupled)
>> +{
>> + int i;
>> + int state = INT_MAX;
>> +
>> + for_each_cpu_mask(i, coupled->coupled_cpus)
>> + if (coupled->requested_state[i] != CPUIDLE_COUPLED_DEAD &&
>> + coupled->requested_state[i] < state)
>> + state = coupled->requested_state[i];
>> +
>> + BUG_ON(state >= dev->state_count || state < 0);
>
> Do you have to crash the kernel here if the assertion doesn't hold? Maybe
> you could use WARN_ON() and return error code?
If this BUG_ON is hit, there is a race condition somewhere that
allowed a cpu out of idle unexpectedly, and there is no way to recover
without more race conditions. I don't expect this to ever happen, it
is mostly there to detect race conditions during development. Should
I drop it completely?
>> +
>> + return state;
>> +}
>> +
>> +static void cpuidle_coupled_poked(void *info)
>> +{
>> + int cpu = (unsigned long)info;
>> + cpumask_clear_cpu(cpu, &cpuidle_coupled_poked_mask);
>> +}
>> +
>> +/**
>> + * cpuidle_coupled_poke - wake up a cpu that may be waiting
>> + * @cpu: target cpu
>> + *
>> + * Ensures that the target cpu exits it's waiting idle state (if it is in it)
>> + * and will see updates to waiting_count before it re-enters it's waiting idle
>> + * state.
>> + *
>> + * If cpuidle_coupled_poked_mask is already set for the target cpu, that cpu
>> + * either has or will soon have a pending IPI that will wake it out of idle,
>> + * or it is currently processing the IPI and is not in idle.
>> + */
>> +static void cpuidle_coupled_poke(int cpu)
>> +{
>> + struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
>> +
>> + if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
>> + __smp_call_function_single(cpu, csd, 0);
>> +}
>> +
>> +/**
>> + * cpuidle_coupled_poke_others - wake up all other cpus that may be waiting
>> + * @dev: struct cpuidle_device for this cpu
>> + * @coupled: the struct coupled that contains the current cpu
>> + *
>> + * Calls cpuidle_coupled_poke on all other online cpus.
>> + */
>> +static void cpuidle_coupled_poke_others(struct cpuidle_device *dev,
>> + struct cpuidle_coupled *coupled)
>
> It looks like you could simply pass cpu (not dev) to this function.
OK.
>> +{
>> + int cpu;
>> +
>> + for_each_cpu_mask(cpu, coupled->coupled_cpus)
>> + if (cpu != dev->cpu && cpu_online(cpu))
>> + cpuidle_coupled_poke(cpu);
>> +}
>> +
>> +/**
>> + * cpuidle_coupled_set_waiting - mark this cpu as in the wait loop
>> + * @dev: struct cpuidle_device for this cpu
>> + * @coupled: the struct coupled that contains the current cpu
>> + * @next_state: the index in drv->states of the requested state for this cpu
>> + *
>> + * Updates the requested idle state for the specified cpuidle device,
>> + * poking all coupled cpus out of idle if necessary to let them see the new
>> + * state.
>> + *
>> + * Provides memory ordering around waiting_count.
>> + */
>> +static void cpuidle_coupled_set_waiting(struct cpuidle_device *dev,
>> + struct cpuidle_coupled *coupled, int next_state)
>
> If you passed cpu (instead of dev) to cpuidle_coupled_poke_others(),
> then you could pass cpu (instead of dev) to this function too, it seems.
OK.
>> +{
>> + int alive;
>> +
>> + BUG_ON(coupled->requested_state[dev->cpu] >= 0);
>
> Would be WARN_ON() + do nothing too dangerous here?
If this BUG_ON is hit, then this cpu exited idle without clearing its
waiting state, which could cause another cpu to enter the deeper idle
state while this cpu is still running. The counters would be out of
sync, so it's not easy to recover. Again, this is to detect race
conditions during development, but should never happen. Should I drop
it?
>> +
>> + coupled->requested_state[dev->cpu] = next_state;
>> +
>> + /*
>> + * If this is the last cpu to enter the waiting state, poke
>> + * all the other cpus out of their waiting state so they can
>> + * enter a deeper state. This can race with one of the cpus
>> + * exiting the waiting state due to an interrupt and
>> + * decrementing waiting_count, see comment below.
>> + */
>> + alive = atomic_read(&coupled->alive_count);
>> + if (atomic_inc_return(&coupled->waiting_count) == alive)
>> + cpuidle_coupled_poke_others(dev, coupled);
>> +}
>> +
>> +/**
>> + * cpuidle_coupled_set_not_waiting - mark this cpu as leaving the wait loop
>> + * @dev: struct cpuidle_device for this cpu
>> + * @coupled: the struct coupled that contains the current cpu
>> + *
>> + * Removes the requested idle state for the specified cpuidle device.
>> + *
>> + * Provides memory ordering around waiting_count.
>> + */
>> +static void cpuidle_coupled_set_not_waiting(struct cpuidle_device *dev,
>> + struct cpuidle_coupled *coupled)
>
> It looks like dev doesn't have to be passed here, cpu would be enough.
>
>> +{
>> + BUG_ON(coupled->requested_state[dev->cpu] < 0);
>
> Well, like above?
Same as above.
>> +
>> + /*
>> + * Decrementing waiting_count can race with incrementing it in
>> + * cpuidle_coupled_set_waiting, but that's OK. Worst case, some
>> + * cpus will increment ready_count and then spin until they
>> + * notice that this cpu has cleared it's requested_state.
>> + */
>
> So it looks like having ready_count and waiting_count in one atomic variable
> can spare us this particular race condition.
As above, there are 3 counters here, alive, ready, and waiting.
>> +
>> + smp_mb__before_atomic_dec();
>> + atomic_dec(&coupled->waiting_count);
>> + smp_mb__after_atomic_dec();
>
> Do you really need both the before and after barriers here? If so, then why?
I believe so, waiting is ordered vs. alive and ready, one barrier is
for each. Do you want the answers to these questions here or in the
code? I had comments for every barrier use during development, but it
made it too hard to follow the flow of the code. I could add a
comment describing the ordering requirements instead, but it's still
hard to translate that to the required barrier locations.
>> +
>> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
>> +}
>> +
>> +/**
>> + * cpuidle_enter_state_coupled - attempt to enter a state with coupled cpus
>> + * @dev: struct cpuidle_device for the current cpu
>> + * @drv: struct cpuidle_driver for the platform
>> + * @next_state: index of the requested state in drv->states
>> + *
>> + * Coordinate with coupled cpus to enter the target state. This is a two
>> + * stage process. In the first stage, the cpus are operating independently,
>> + * and may call into cpuidle_enter_state_coupled at completely different times.
>> + * To save as much power as possible, the first cpus to call this function will
>> + * go to an intermediate state (the cpuidle_device's safe state), and wait for
>> + * all the other cpus to call this function. Once all coupled cpus are idle,
>> + * the second stage will start. Each coupled cpu will spin until all cpus have
>> + * guaranteed that they will call the target_state.
>
> It would be good to mention the conditions for calling this function (eg.
> interrupts disabled on the local CPU).
OK.
>> + */
>> +int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv, int next_state)
>> +{
>> + int entered_state = -1;
>> + struct cpuidle_coupled *coupled = dev->coupled;
>> + int alive;
>> +
>> + if (!coupled)
>> + return -EINVAL;
>> +
>> + BUG_ON(atomic_read(&coupled->ready_count));
>
> Again, I'd do a WARN_ON() and return error code from here (to avoid crashing
> the kernel).
Same as above, if ready_count is not 0 here then the counters are out
of sync and something is about to go horribly wrong, like cutting
power to a running cpu.
>> + cpuidle_coupled_set_waiting(dev, coupled, next_state);
>> +
>> +retry:
>> + /*
>> + * Wait for all coupled cpus to be idle, using the deepest state
>> + * allowed for a single cpu.
>> + */
>> + while (!need_resched() && !cpuidle_coupled_cpus_waiting(coupled)) {
>> + entered_state = cpuidle_enter_state(dev, drv,
>> + dev->safe_state_index);
>> +
>> + local_irq_enable();
>> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
>> + cpu_relax();
>
> Hmm. What exactly is this loop supposed to achieve?
This is to ensure that the outstanding wakeups have been processed so
we don't go to idle with an interrupt pending an immediately wake up.
>> + local_irq_disable();
>
> Anyway, you seem to be calling it twice along with this enabling/disabling of
> interrupts. I'd put that into a separate function and explain its role in a
> kerneldoc comment.
I left it here to be obvious that I was enabling interrupts in the
idle path, but I can refactor it out if you prefer.
>> + }
>> +
>> + /* give a chance to process any remaining pokes */
>> + local_irq_enable();
>> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
>> + cpu_relax();
>> + local_irq_disable();
>> +
>> + if (need_resched()) {
>> + cpuidle_coupled_set_not_waiting(dev, coupled);
>> + goto out;
>> + }
>> +
>> + /*
>> + * All coupled cpus are probably idle. There is a small chance that
>> + * one of the other cpus just became active. Increment a counter when
>> + * ready, and spin until all coupled cpus have incremented the counter.
>> + * Once a cpu has incremented the counter, it cannot abort idle and must
>> + * spin until either the count has hit alive_count, or another cpu
>> + * leaves idle.
>> + */
>> +
>> + smp_mb__before_atomic_inc();
>> + atomic_inc(&coupled->ready_count);
>> + smp_mb__after_atomic_inc();
>
> It seems that at least one of these barriers is unnecessary ...
The first is to ensure ordering between ready_count and waiting count,
the second is for ready_count vs. alive_count and requested_state.
>> + /* alive_count can't change while ready_count > 0 */
>> + alive = atomic_read(&coupled->alive_count);
>> + while (atomic_read(&coupled->ready_count) != alive) {
>> + /* Check if any other cpus bailed out of idle. */
>> + if (!cpuidle_coupled_cpus_waiting(coupled)) {
>> + atomic_dec(&coupled->ready_count);
>> + smp_mb__after_atomic_dec();
>> + goto retry;
>> + }
>> +
>> + cpu_relax();
>> + }
>> +
>> + /* all cpus have acked the coupled state */
>> + smp_rmb();
>
> What is the barrier here for?
This protects ready_count vs. requested_state. It is already
implicitly protected by the atomic_inc_return in set_waiting, but I
thought it would be better to protect it explicitly here. I think I
added the smp_mb__after_atomic_inc above later, which makes this one
superflous, so I'll drop it.
>> +
>> + next_state = cpuidle_coupled_get_state(dev, coupled);
>> +
>> + entered_state = cpuidle_enter_state(dev, drv, next_state);
>> +
>> + cpuidle_coupled_set_not_waiting(dev, coupled);
>> + atomic_dec(&coupled->ready_count);
>> + smp_mb__after_atomic_dec();
>> +
>> +out:
>> + /*
>> + * Normal cpuidle states are expected to return with irqs enabled.
>> + * That leads to an inefficiency where a cpu receiving an interrupt
>> + * that brings it out of idle will process that interrupt before
>> + * exiting the idle enter function and decrementing ready_count. All
>> + * other cpus will need to spin waiting for the cpu that is processing
>> + * the interrupt. If the driver returns with interrupts disabled,
>> + * all other cpus will loop back into the safe idle state instead of
>> + * spinning, saving power.
>> + *
>> + * Calling local_irq_enable here allows coupled states to return with
>> + * interrupts disabled, but won't cause problems for drivers that
>> + * exit with interrupts enabled.
>> + */
>> + local_irq_enable();
>> +
>> + /*
>> + * Wait until all coupled cpus have exited idle. There is no risk that
>> + * a cpu exits and re-enters the ready state because this cpu has
>> + * already decremented its waiting_count.
>> + */
>> + while (atomic_read(&coupled->ready_count) != 0)
>> + cpu_relax();
>> +
>> + smp_rmb();
>
> And here?
This was to protect ready_count vs. looping back in and reading
alive_count. There will be plenty of synchronization calls between
the two with implicit barriers, but I thought it was better to do it
explicitly.
>> +
>> + return entered_state;
>> +}
>> +
>> +/**
>> + * cpuidle_coupled_register_device - register a coupled cpuidle device
>> + * @dev: struct cpuidle_device for the current cpu
>> + *
>> + * Called from cpuidle_register_device to handle coupled idle init. Finds the
>> + * cpuidle_coupled struct for this set of coupled cpus, or creates one if none
>> + * exists yet.
>> + */
>> +int cpuidle_coupled_register_device(struct cpuidle_device *dev)
>> +{
>> + int cpu;
>> + struct cpuidle_device *other_dev;
>> + struct call_single_data *csd;
>> + struct cpuidle_coupled *coupled;
>> +
>> + if (cpumask_empty(&dev->coupled_cpus))
>> + return 0;
>> +
>> + for_each_cpu_mask(cpu, dev->coupled_cpus) {
>> + other_dev = per_cpu(cpuidle_devices, cpu);
>> + if (other_dev && other_dev->coupled) {
>> + coupled = other_dev->coupled;
>> + goto have_coupled;
>> + }
>> + }
>> +
>> + /* No existing coupled info found, create a new one */
>> + coupled = kzalloc(sizeof(struct cpuidle_coupled), GFP_KERNEL);
>> + if (!coupled)
>> + return -ENOMEM;
>> +
>> + coupled->coupled_cpus = dev->coupled_cpus;
>> + for_each_cpu_mask(cpu, coupled->coupled_cpus)
>> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_DEAD;
>> +
>> +have_coupled:
>> + dev->coupled = coupled;
>> + BUG_ON(!cpumask_equal(&dev->coupled_cpus, &coupled->coupled_cpus));
>> +
>> + if (cpu_online(dev->cpu)) {
>> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
>> + atomic_inc(&coupled->alive_count);
>> + }
>> +
>> + coupled->refcnt++;
>> +
>> + csd = &per_cpu(cpuidle_coupled_poke_cb, dev->cpu);
>> + csd->func = cpuidle_coupled_poked;
>> + csd->info = (void *)(unsigned long)dev->cpu;
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> + * cpuidle_coupled_unregister_device - unregister a coupled cpuidle device
>> + * @dev: struct cpuidle_device for the current cpu
>> + *
>> + * Called from cpuidle_unregister_device to tear down coupled idle. Removes the
>> + * cpu from the coupled idle set, and frees the cpuidle_coupled_info struct if
>> + * this was the last cpu in the set.
>> + */
>> +void cpuidle_coupled_unregister_device(struct cpuidle_device *dev)
>> +{
>> + struct cpuidle_coupled *coupled = dev->coupled;
>> +
>> + if (cpumask_empty(&dev->coupled_cpus))
>> + return;
>> +
>> + if (--coupled->refcnt)
>> + kfree(coupled);
>> + dev->coupled = NULL;
>> +}
>> +
>> +/**
>> + * cpuidle_coupled_cpu_set_alive - adjust alive_count during hotplug transitions
>> + * @cpu: target cpu number
>> + * @alive: whether the target cpu is going up or down
>> + *
>> + * Run on the cpu that is bringing up the target cpu, before the target cpu
>> + * has been booted, or after the target cpu is completely dead.
>> + */
>> +static void cpuidle_coupled_cpu_set_alive(int cpu, bool alive)
>> +{
>> + struct cpuidle_device *dev;
>> + struct cpuidle_coupled *coupled;
>> +
>> + mutex_lock(&cpuidle_lock);
>> +
>> + dev = per_cpu(cpuidle_devices, cpu);
>> + if (!dev->coupled)
>> + goto out;
>> +
>> + coupled = dev->coupled;
>> +
>> + /*
>> + * waiting_count must be at least 1 less than alive_count, because
>> + * this cpu is not waiting. Spin until all cpus have noticed this cpu
>> + * is not idle and exited the ready loop before changing alive_count.
>> + */
>> + while (atomic_read(&coupled->ready_count))
>> + cpu_relax();
>> +
>> + if (alive) {
>> + smp_mb__before_atomic_inc();
>> + atomic_inc(&coupled->alive_count);
>> + smp_mb__after_atomic_inc();
>> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
>> + } else {
>> + smp_mb__before_atomic_dec();
>> + atomic_dec(&coupled->alive_count);
>> + smp_mb__after_atomic_dec();
>> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_DEAD;
>
> There's too many SMP barriers above, but I'm not quite sure which of them (if
> any) are really necessary.
The ones before order ready_count vs alive_count, the ones after order
alive_count vs. requested_state and future waiting_count increments.
>> + }
>> +
>> +out:
>> + mutex_unlock(&cpuidle_lock);
>> +}
>> +
>> +/**
>> + * cpuidle_coupled_cpu_notify - notifier called during hotplug transitions
>> + * @nb: notifier block
>> + * @action: hotplug transition
>> + * @hcpu: target cpu number
>> + *
>> + * Called when a cpu is brought on or offline using hotplug. Updates the
>> + * coupled cpu set appropriately
>> + */
>> +static int cpuidle_coupled_cpu_notify(struct notifier_block *nb,
>> + unsigned long action, void *hcpu)
>> +{
>> + int cpu = (unsigned long)hcpu;
>> +
>> + switch (action & ~CPU_TASKS_FROZEN) {
>> + case CPU_DEAD:
>> + case CPU_UP_CANCELED:
>> + cpuidle_coupled_cpu_set_alive(cpu, false);
>> + break;
>> + case CPU_UP_PREPARE:
>> + cpuidle_coupled_cpu_set_alive(cpu, true);
>> + break;
>> + }
>> + return NOTIFY_OK;
>> +}
>> +
>> +static struct notifier_block cpuidle_coupled_cpu_notifier = {
>> + .notifier_call = cpuidle_coupled_cpu_notify,
>> +};
>> +
>> +static int __init cpuidle_coupled_init(void)
>> +{
>> + return register_cpu_notifier(&cpuidle_coupled_cpu_notifier);
>> +}
>> +core_initcall(cpuidle_coupled_init);
>> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
>> index 4540672..e81cfda 100644
>> --- a/drivers/cpuidle/cpuidle.c
>> +++ b/drivers/cpuidle/cpuidle.c
>> @@ -171,7 +171,11 @@ int cpuidle_idle_call(void)
>> trace_power_start_rcuidle(POWER_CSTATE, next_state, dev->cpu);
>> trace_cpu_idle_rcuidle(next_state, dev->cpu);
>>
>> - entered_state = cpuidle_enter_state(dev, drv, next_state);
>> + if (cpuidle_state_is_coupled(dev, drv, next_state))
>> + entered_state = cpuidle_enter_state_coupled(dev, drv,
>> + next_state);
>> + else
>> + entered_state = cpuidle_enter_state(dev, drv, next_state);
>>
>> trace_power_end_rcuidle(dev->cpu);
>> trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
>> @@ -407,9 +411,16 @@ static int __cpuidle_register_device(struct cpuidle_device *dev)
>> if (ret)
>> goto err_sysfs;
>>
>> + ret = cpuidle_coupled_register_device(dev);
>> + if (ret)
>> + goto err_coupled;
>> +
>> dev->registered = 1;
>> return 0;
>>
>> +err_coupled:
>> + cpuidle_remove_sysfs(cpu_dev);
>> + wait_for_completion(&dev->kobj_unregister);
>> err_sysfs:
>> list_del(&dev->device_list);
>> per_cpu(cpuidle_devices, dev->cpu) = NULL;
>> @@ -464,6 +475,8 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
>> wait_for_completion(&dev->kobj_unregister);
>> per_cpu(cpuidle_devices, dev->cpu) = NULL;
>>
>> + cpuidle_coupled_unregister_device(dev);
>> +
>> cpuidle_resume_and_unlock();
>>
>> module_put(cpuidle_driver->owner);
>> diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
>> index d8a3ccc..76e7f69 100644
>> --- a/drivers/cpuidle/cpuidle.h
>> +++ b/drivers/cpuidle/cpuidle.h
>> @@ -32,4 +32,34 @@ extern int cpuidle_enter_state(struct cpuidle_device *dev,
>> extern int cpuidle_add_sysfs(struct device *dev);
>> extern void cpuidle_remove_sysfs(struct device *dev);
>>
>> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>> +bool cpuidle_state_is_coupled(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv, int state);
>> +int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv, int next_state);
>> +int cpuidle_coupled_register_device(struct cpuidle_device *dev);
>> +void cpuidle_coupled_unregister_device(struct cpuidle_device *dev);
>> +#else
>> +static inline bool cpuidle_state_is_coupled(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv, int state)
>> +{
>> + return false;
>> +}
>> +
>> +static inline int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv, int next_state)
>> +{
>> + return -1;
>> +}
>> +
>> +static inline int cpuidle_coupled_register_device(struct cpuidle_device *dev)
>> +{
>> + return 0;
>> +}
>> +
>> +static inline void cpuidle_coupled_unregister_device(struct cpuidle_device *dev)
>> +{
>> +}
>> +#endif
>> +
>> #endif /* __DRIVER_CPUIDLE_H */
>> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
>> index 6c26a3d..6038448 100644
>> --- a/include/linux/cpuidle.h
>> +++ b/include/linux/cpuidle.h
>> @@ -57,6 +57,7 @@ struct cpuidle_state {
>>
>> /* Idle State Flags */
>> #define CPUIDLE_FLAG_TIME_VALID (0x01) /* is residency time measurable? */
>> +#define CPUIDLE_FLAG_COUPLED (0x02) /* state applies to multiple cpus */
>>
>> #define CPUIDLE_DRIVER_FLAGS_MASK (0xFFFF0000)
>>
>> @@ -100,6 +101,12 @@ struct cpuidle_device {
>> struct list_head device_list;
>> struct kobject kobj;
>> struct completion kobj_unregister;
>> +
>> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>> + int safe_state_index;
>> + cpumask_t coupled_cpus;
>> + struct cpuidle_coupled *coupled;
>> +#endif
>> };
>>
>> DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
>
> Thanks,
> Rafael
^ permalink raw reply
* Re: [PATCHv3 3/5] cpuidle: add support for states that affect multiple cpus
From: Rafael J. Wysocki @ 2012-05-03 22:14 UTC (permalink / raw)
To: linux-pm
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, Colin Cross,
Arnd Bergmann, Arjan van de Ven, linux-arm-kernel
In-Reply-To: <1335816551-27756-4-git-send-email-ccross@android.com>
On Monday, April 30, 2012, Colin Cross wrote:
> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> cpus cannot be independently powered down, either due to
> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> power down), or due to HW bugs (on OMAP4460, a cpu powering up
> will corrupt the gic state unless the other cpu runs a work
> around). Each cpu has a power state that it can enter without
> coordinating with the other cpu (usually Wait For Interrupt, or
> WFI), and one or more "coupled" power states that affect blocks
> shared between the cpus (L2 cache, interrupt controller, and
> sometimes the whole SoC). Entering a coupled power state must
> be tightly controlled on both cpus.
>
> The easiest solution to implementing coupled cpu power states is
> to hotplug all but one cpu whenever possible, usually using a
> cpufreq governor that looks at cpu load to determine when to
> enable the secondary cpus. This causes problems, as hotplug is an
> expensive operation, so the number of hotplug transitions must be
> minimized, leading to very slow response to loads, often on the
> order of seconds.
>
> This file implements an alternative solution, where each cpu will
> wait in the WFI state until all cpus are ready to enter a coupled
> state, at which point the coupled state function will be called
> on all cpus at approximately the same time.
>
> Once all cpus are ready to enter idle, they are woken by an smp
> cross call. At this point, there is a chance that one of the
> cpus will find work to do, and choose not to enter idle. A
> final pass is needed to guarantee that all cpus will call the
> power state enter function at the same time. During this pass,
> each cpu will increment the ready counter, and continue once the
> ready counter matches the number of online coupled cpus. If any
> cpu exits idle, the other cpus will decrement their counter and
> retry.
>
> To use coupled cpuidle states, a cpuidle driver must:
>
> Set struct cpuidle_device.coupled_cpus to the mask of all
> coupled cpus, usually the same as cpu_possible_mask if all cpus
> are part of the same cluster. The coupled_cpus mask must be
> set in the struct cpuidle_device for each cpu.
>
> Set struct cpuidle_device.safe_state to a state that is not a
> coupled state. This is usually WFI.
>
> Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
> state that affects multiple cpus.
>
> Provide a struct cpuidle_state.enter function for each state
> that affects multiple cpus. This function is guaranteed to be
> called on all cpus at approximately the same time. The driver
> should ensure that the cpus all abort together if any cpu tries
> to abort once the function is called.
>
> Cc: Len Brown <len.brown@intel.com>
> Cc: Amit Kucheria <amit.kucheria@linaro.org>
> Cc: Arjan van de Ven <arjan@linux.intel.com>
> Cc: Trinabh Gupta <g.trinabh@gmail.com>
> Cc: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> Tested-by: Kevin Hilman <khilman@ti.com>
> Signed-off-by: Colin Cross <ccross@android.com>
> ---
> drivers/cpuidle/Kconfig | 3 +
> drivers/cpuidle/Makefile | 1 +
> drivers/cpuidle/coupled.c | 571 +++++++++++++++++++++++++++++++++++++++++++++
> drivers/cpuidle/cpuidle.c | 15 ++-
> drivers/cpuidle/cpuidle.h | 30 +++
> include/linux/cpuidle.h | 7 +
> 6 files changed, 626 insertions(+), 1 deletions(-)
> create mode 100644 drivers/cpuidle/coupled.c
>
> v2:
> * removed the coupled lock, replacing it with atomic counters
> * added a check for outstanding pokes before beginning the
> final transition to avoid extra wakeups
> * made the cpuidle_coupled struct completely private
> * fixed kerneldoc comment formatting
>
> v3:
> * fixed decrement in cpuidle_coupled_cpu_set_alive
> * added kerneldoc annotation to the description
>
> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index 78a666d..a76b689 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig
> @@ -18,3 +18,6 @@ config CPU_IDLE_GOV_MENU
> bool
> depends on CPU_IDLE && NO_HZ
> default y
> +
> +config ARCH_NEEDS_CPU_IDLE_COUPLED
> + def_bool n
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index 5634f88..38c8f69 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -3,3 +3,4 @@
> #
>
> obj-y += cpuidle.o driver.o governor.o sysfs.o governors/
> +obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
> diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> new file mode 100644
> index 0000000..d097826
> --- /dev/null
> +++ b/drivers/cpuidle/coupled.c
> @@ -0,0 +1,571 @@
> +/*
> + * coupled.c - helper functions to enter the same idle state on multiple cpus
> + *
> + * Copyright (c) 2011 Google, Inc.
> + *
> + * Author: Colin Cross <ccross@android.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/cpu.h>
> +#include <linux/cpuidle.h>
> +#include <linux/mutex.h>
> +#include <linux/sched.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +#include "cpuidle.h"
> +
> +/**
> + * DOC: Coupled cpuidle states
> + *
> + * On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> + * cpus cannot be independently powered down, either due to
> + * sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> + * power down), or due to HW bugs (on OMAP4460, a cpu powering up
> + * will corrupt the gic state unless the other cpu runs a work
> + * around). Each cpu has a power state that it can enter without
> + * coordinating with the other cpu (usually Wait For Interrupt, or
> + * WFI), and one or more "coupled" power states that affect blocks
> + * shared between the cpus (L2 cache, interrupt controller, and
> + * sometimes the whole SoC). Entering a coupled power state must
> + * be tightly controlled on both cpus.
> + *
> + * The easiest solution to implementing coupled cpu power states is
> + * to hotplug all but one cpu whenever possible, usually using a
> + * cpufreq governor that looks at cpu load to determine when to
> + * enable the secondary cpus. This causes problems, as hotplug is an
> + * expensive operation, so the number of hotplug transitions must be
> + * minimized, leading to very slow response to loads, often on the
> + * order of seconds.
I'd drop the above paragraph entirely. It doesn't say much about what's in
the file and refers to an obviously suboptimal approach.
> + *
> + * This file implements an alternative solution, where each cpu will
> + * wait in the WFI state until all cpus are ready to enter a coupled
> + * state, at which point the coupled state function will be called
> + * on all cpus at approximately the same time.
> + *
> + * Once all cpus are ready to enter idle, they are woken by an smp
> + * cross call. At this point, there is a chance that one of the
> + * cpus will find work to do, and choose not to enter idle. A
> + * final pass is needed to guarantee that all cpus will call the
> + * power state enter function at the same time. During this pass,
> + * each cpu will increment the ready counter, and continue once the
> + * ready counter matches the number of online coupled cpus. If any
> + * cpu exits idle, the other cpus will decrement their counter and
> + * retry.
> + *
> + * requested_state stores the deepest coupled idle state each cpu
> + * is ready for. It is assumed that the states are indexed from
> + * shallowest (highest power, lowest exit latency) to deepest
> + * (lowest power, highest exit latency). The requested_state
> + * variable is not locked. It is only written from the cpu that
> + * it stores (or by the on/offlining cpu if that cpu is offline),
> + * and only read after all the cpus are ready for the coupled idle
> + * state are are no longer updating it.
> + *
> + * Three atomic counters are used. alive_count tracks the number
> + * of cpus in the coupled set that are currently or soon will be
> + * online. waiting_count tracks the number of cpus that are in
> + * the waiting loop, in the ready loop, or in the coupled idle state.
> + * ready_count tracks the number of cpus that are in the ready loop
> + * or in the coupled idle state.
> + *
> + * To use coupled cpuidle states, a cpuidle driver must:
> + *
> + * Set struct cpuidle_device.coupled_cpus to the mask of all
> + * coupled cpus, usually the same as cpu_possible_mask if all cpus
> + * are part of the same cluster. The coupled_cpus mask must be
> + * set in the struct cpuidle_device for each cpu.
> + *
> + * Set struct cpuidle_device.safe_state to a state that is not a
> + * coupled state. This is usually WFI.
> + *
> + * Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
> + * state that affects multiple cpus.
> + *
> + * Provide a struct cpuidle_state.enter function for each state
> + * that affects multiple cpus. This function is guaranteed to be
> + * called on all cpus at approximately the same time. The driver
> + * should ensure that the cpus all abort together if any cpu tries
> + * to abort once the function is called. The function should return
> + * with interrupts still disabled.
> + */
> +
> +/**
> + * struct cpuidle_coupled - data for set of cpus that share a coupled idle state
> + * @coupled_cpus: mask of cpus that are part of the coupled set
> + * @requested_state: array of requested states for cpus in the coupled set
> + * @ready_count: count of cpus that are ready for the final idle transition
> + * @waiting_count: count of cpus that are waiting for all other cpus to be idle
> + * @alive_count: count of cpus that are online or soon will be
> + * @refcnt: reference count of cpuidle devices that are using this struct
> + */
> +struct cpuidle_coupled {
> + cpumask_t coupled_cpus;
> + int requested_state[NR_CPUS];
> + atomic_t ready_count;
> + atomic_t waiting_count;
> + atomic_t alive_count;
> + int refcnt;
> +};
> +
> +#define CPUIDLE_COUPLED_NOT_IDLE (-1)
> +#define CPUIDLE_COUPLED_DEAD (-2)
> +
> +static DEFINE_MUTEX(cpuidle_coupled_lock);
> +static DEFINE_PER_CPU(struct call_single_data, cpuidle_coupled_poke_cb);
> +
> +/*
> + * The cpuidle_coupled_poked_mask masked is used to avoid calling
s/masked/mask/ perhaps?
> + * __smp_call_function_single with the per cpu call_single_data struct already
> + * in use. This prevents a deadlock where two cpus are waiting for each others
> + * call_single_data struct to be available
> + */
> +static cpumask_t cpuidle_coupled_poked_mask;
> +
> +/**
> + * cpuidle_state_is_coupled - check if a state is part of a coupled set
> + * @dev: struct cpuidle_device for the current cpu
> + * @drv: struct cpuidle_driver for the platform
> + * @state: index of the target state in drv->states
> + *
> + * Returns true if the target state is coupled with cpus besides this one
> + */
> +bool cpuidle_state_is_coupled(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int state)
> +{
> + return drv->states[state].flags & CPUIDLE_FLAG_COUPLED;
> +}
> +
> +/**
> + * cpuidle_coupled_cpus_waiting - check if all cpus in a coupled set are waiting
> + * @coupled: the struct coupled that contains the current cpu
> + *
> + * Returns true if all cpus coupled to this target state are in the wait loop
> + */
> +static inline bool cpuidle_coupled_cpus_waiting(struct cpuidle_coupled *coupled)
> +{
> + int alive;
> + int waiting;
> +
> + /*
> + * Read alive before reading waiting so a booting cpu is not treated as
> + * idle
> + */
Well, the comment doesn't really explain much. In particular, why the boot CPU
could be treated as idle if the reads were in a different order.
> + alive = atomic_read(&coupled->alive_count);
> + smp_rmb();
> + waiting = atomic_read(&coupled->waiting_count);
Have you considered using one atomic variable to accommodate both counters
such that the upper half contains one counter and the lower half contains
the other?
> +
> + return (waiting == alive);
> +}
> +
> +/**
> + * cpuidle_coupled_get_state - determine the deepest idle state
> + * @dev: struct cpuidle_device for this cpu
> + * @coupled: the struct coupled that contains the current cpu
> + *
> + * Returns the deepest idle state that all coupled cpus can enter
> + */
> +static inline int cpuidle_coupled_get_state(struct cpuidle_device *dev,
> + struct cpuidle_coupled *coupled)
> +{
> + int i;
> + int state = INT_MAX;
> +
> + for_each_cpu_mask(i, coupled->coupled_cpus)
> + if (coupled->requested_state[i] != CPUIDLE_COUPLED_DEAD &&
> + coupled->requested_state[i] < state)
> + state = coupled->requested_state[i];
> +
> + BUG_ON(state >= dev->state_count || state < 0);
Do you have to crash the kernel here if the assertion doesn't hold? Maybe
you could use WARN_ON() and return error code?
> +
> + return state;
> +}
> +
> +static void cpuidle_coupled_poked(void *info)
> +{
> + int cpu = (unsigned long)info;
> + cpumask_clear_cpu(cpu, &cpuidle_coupled_poked_mask);
> +}
> +
> +/**
> + * cpuidle_coupled_poke - wake up a cpu that may be waiting
> + * @cpu: target cpu
> + *
> + * Ensures that the target cpu exits it's waiting idle state (if it is in it)
> + * and will see updates to waiting_count before it re-enters it's waiting idle
> + * state.
> + *
> + * If cpuidle_coupled_poked_mask is already set for the target cpu, that cpu
> + * either has or will soon have a pending IPI that will wake it out of idle,
> + * or it is currently processing the IPI and is not in idle.
> + */
> +static void cpuidle_coupled_poke(int cpu)
> +{
> + struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
> +
> + if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
> + __smp_call_function_single(cpu, csd, 0);
> +}
> +
> +/**
> + * cpuidle_coupled_poke_others - wake up all other cpus that may be waiting
> + * @dev: struct cpuidle_device for this cpu
> + * @coupled: the struct coupled that contains the current cpu
> + *
> + * Calls cpuidle_coupled_poke on all other online cpus.
> + */
> +static void cpuidle_coupled_poke_others(struct cpuidle_device *dev,
> + struct cpuidle_coupled *coupled)
It looks like you could simply pass cpu (not dev) to this function.
> +{
> + int cpu;
> +
> + for_each_cpu_mask(cpu, coupled->coupled_cpus)
> + if (cpu != dev->cpu && cpu_online(cpu))
> + cpuidle_coupled_poke(cpu);
> +}
> +
> +/**
> + * cpuidle_coupled_set_waiting - mark this cpu as in the wait loop
> + * @dev: struct cpuidle_device for this cpu
> + * @coupled: the struct coupled that contains the current cpu
> + * @next_state: the index in drv->states of the requested state for this cpu
> + *
> + * Updates the requested idle state for the specified cpuidle device,
> + * poking all coupled cpus out of idle if necessary to let them see the new
> + * state.
> + *
> + * Provides memory ordering around waiting_count.
> + */
> +static void cpuidle_coupled_set_waiting(struct cpuidle_device *dev,
> + struct cpuidle_coupled *coupled, int next_state)
If you passed cpu (instead of dev) to cpuidle_coupled_poke_others(),
then you could pass cpu (instead of dev) to this function too, it seems.
> +{
> + int alive;
> +
> + BUG_ON(coupled->requested_state[dev->cpu] >= 0);
Would be WARN_ON() + do nothing too dangerous here?
> +
> + coupled->requested_state[dev->cpu] = next_state;
> +
> + /*
> + * If this is the last cpu to enter the waiting state, poke
> + * all the other cpus out of their waiting state so they can
> + * enter a deeper state. This can race with one of the cpus
> + * exiting the waiting state due to an interrupt and
> + * decrementing waiting_count, see comment below.
> + */
> + alive = atomic_read(&coupled->alive_count);
> + if (atomic_inc_return(&coupled->waiting_count) == alive)
> + cpuidle_coupled_poke_others(dev, coupled);
> +}
> +
> +/**
> + * cpuidle_coupled_set_not_waiting - mark this cpu as leaving the wait loop
> + * @dev: struct cpuidle_device for this cpu
> + * @coupled: the struct coupled that contains the current cpu
> + *
> + * Removes the requested idle state for the specified cpuidle device.
> + *
> + * Provides memory ordering around waiting_count.
> + */
> +static void cpuidle_coupled_set_not_waiting(struct cpuidle_device *dev,
> + struct cpuidle_coupled *coupled)
It looks like dev doesn't have to be passed here, cpu would be enough.
> +{
> + BUG_ON(coupled->requested_state[dev->cpu] < 0);
Well, like above?
> +
> + /*
> + * Decrementing waiting_count can race with incrementing it in
> + * cpuidle_coupled_set_waiting, but that's OK. Worst case, some
> + * cpus will increment ready_count and then spin until they
> + * notice that this cpu has cleared it's requested_state.
> + */
So it looks like having ready_count and waiting_count in one atomic variable
can spare us this particular race condition.
> +
> + smp_mb__before_atomic_dec();
> + atomic_dec(&coupled->waiting_count);
> + smp_mb__after_atomic_dec();
Do you really need both the before and after barriers here? If so, then why?
> +
> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
> +}
> +
> +/**
> + * cpuidle_enter_state_coupled - attempt to enter a state with coupled cpus
> + * @dev: struct cpuidle_device for the current cpu
> + * @drv: struct cpuidle_driver for the platform
> + * @next_state: index of the requested state in drv->states
> + *
> + * Coordinate with coupled cpus to enter the target state. This is a two
> + * stage process. In the first stage, the cpus are operating independently,
> + * and may call into cpuidle_enter_state_coupled at completely different times.
> + * To save as much power as possible, the first cpus to call this function will
> + * go to an intermediate state (the cpuidle_device's safe state), and wait for
> + * all the other cpus to call this function. Once all coupled cpus are idle,
> + * the second stage will start. Each coupled cpu will spin until all cpus have
> + * guaranteed that they will call the target_state.
It would be good to mention the conditions for calling this function (eg.
interrupts disabled on the local CPU).
> + */
> +int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int next_state)
> +{
> + int entered_state = -1;
> + struct cpuidle_coupled *coupled = dev->coupled;
> + int alive;
> +
> + if (!coupled)
> + return -EINVAL;
> +
> + BUG_ON(atomic_read(&coupled->ready_count));
Again, I'd do a WARN_ON() and return error code from here (to avoid crashing
the kernel).
> + cpuidle_coupled_set_waiting(dev, coupled, next_state);
> +
> +retry:
> + /*
> + * Wait for all coupled cpus to be idle, using the deepest state
> + * allowed for a single cpu.
> + */
> + while (!need_resched() && !cpuidle_coupled_cpus_waiting(coupled)) {
> + entered_state = cpuidle_enter_state(dev, drv,
> + dev->safe_state_index);
> +
> + local_irq_enable();
> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
> + cpu_relax();
Hmm. What exactly is this loop supposed to achieve?
> + local_irq_disable();
Anyway, you seem to be calling it twice along with this enabling/disabling of
interrupts. I'd put that into a separate function and explain its role in a
kerneldoc comment.
> + }
> +
> + /* give a chance to process any remaining pokes */
> + local_irq_enable();
> + while (cpumask_test_cpu(dev->cpu, &cpuidle_coupled_poked_mask))
> + cpu_relax();
> + local_irq_disable();
> +
> + if (need_resched()) {
> + cpuidle_coupled_set_not_waiting(dev, coupled);
> + goto out;
> + }
> +
> + /*
> + * All coupled cpus are probably idle. There is a small chance that
> + * one of the other cpus just became active. Increment a counter when
> + * ready, and spin until all coupled cpus have incremented the counter.
> + * Once a cpu has incremented the counter, it cannot abort idle and must
> + * spin until either the count has hit alive_count, or another cpu
> + * leaves idle.
> + */
> +
> + smp_mb__before_atomic_inc();
> + atomic_inc(&coupled->ready_count);
> + smp_mb__after_atomic_inc();
It seems that at least one of these barriers is unnecessary ...
> + /* alive_count can't change while ready_count > 0 */
> + alive = atomic_read(&coupled->alive_count);
> + while (atomic_read(&coupled->ready_count) != alive) {
> + /* Check if any other cpus bailed out of idle. */
> + if (!cpuidle_coupled_cpus_waiting(coupled)) {
> + atomic_dec(&coupled->ready_count);
> + smp_mb__after_atomic_dec();
> + goto retry;
> + }
> +
> + cpu_relax();
> + }
> +
> + /* all cpus have acked the coupled state */
> + smp_rmb();
What is the barrier here for?
> +
> + next_state = cpuidle_coupled_get_state(dev, coupled);
> +
> + entered_state = cpuidle_enter_state(dev, drv, next_state);
> +
> + cpuidle_coupled_set_not_waiting(dev, coupled);
> + atomic_dec(&coupled->ready_count);
> + smp_mb__after_atomic_dec();
> +
> +out:
> + /*
> + * Normal cpuidle states are expected to return with irqs enabled.
> + * That leads to an inefficiency where a cpu receiving an interrupt
> + * that brings it out of idle will process that interrupt before
> + * exiting the idle enter function and decrementing ready_count. All
> + * other cpus will need to spin waiting for the cpu that is processing
> + * the interrupt. If the driver returns with interrupts disabled,
> + * all other cpus will loop back into the safe idle state instead of
> + * spinning, saving power.
> + *
> + * Calling local_irq_enable here allows coupled states to return with
> + * interrupts disabled, but won't cause problems for drivers that
> + * exit with interrupts enabled.
> + */
> + local_irq_enable();
> +
> + /*
> + * Wait until all coupled cpus have exited idle. There is no risk that
> + * a cpu exits and re-enters the ready state because this cpu has
> + * already decremented its waiting_count.
> + */
> + while (atomic_read(&coupled->ready_count) != 0)
> + cpu_relax();
> +
> + smp_rmb();
And here?
> +
> + return entered_state;
> +}
> +
> +/**
> + * cpuidle_coupled_register_device - register a coupled cpuidle device
> + * @dev: struct cpuidle_device for the current cpu
> + *
> + * Called from cpuidle_register_device to handle coupled idle init. Finds the
> + * cpuidle_coupled struct for this set of coupled cpus, or creates one if none
> + * exists yet.
> + */
> +int cpuidle_coupled_register_device(struct cpuidle_device *dev)
> +{
> + int cpu;
> + struct cpuidle_device *other_dev;
> + struct call_single_data *csd;
> + struct cpuidle_coupled *coupled;
> +
> + if (cpumask_empty(&dev->coupled_cpus))
> + return 0;
> +
> + for_each_cpu_mask(cpu, dev->coupled_cpus) {
> + other_dev = per_cpu(cpuidle_devices, cpu);
> + if (other_dev && other_dev->coupled) {
> + coupled = other_dev->coupled;
> + goto have_coupled;
> + }
> + }
> +
> + /* No existing coupled info found, create a new one */
> + coupled = kzalloc(sizeof(struct cpuidle_coupled), GFP_KERNEL);
> + if (!coupled)
> + return -ENOMEM;
> +
> + coupled->coupled_cpus = dev->coupled_cpus;
> + for_each_cpu_mask(cpu, coupled->coupled_cpus)
> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_DEAD;
> +
> +have_coupled:
> + dev->coupled = coupled;
> + BUG_ON(!cpumask_equal(&dev->coupled_cpus, &coupled->coupled_cpus));
> +
> + if (cpu_online(dev->cpu)) {
> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
> + atomic_inc(&coupled->alive_count);
> + }
> +
> + coupled->refcnt++;
> +
> + csd = &per_cpu(cpuidle_coupled_poke_cb, dev->cpu);
> + csd->func = cpuidle_coupled_poked;
> + csd->info = (void *)(unsigned long)dev->cpu;
> +
> + return 0;
> +}
> +
> +/**
> + * cpuidle_coupled_unregister_device - unregister a coupled cpuidle device
> + * @dev: struct cpuidle_device for the current cpu
> + *
> + * Called from cpuidle_unregister_device to tear down coupled idle. Removes the
> + * cpu from the coupled idle set, and frees the cpuidle_coupled_info struct if
> + * this was the last cpu in the set.
> + */
> +void cpuidle_coupled_unregister_device(struct cpuidle_device *dev)
> +{
> + struct cpuidle_coupled *coupled = dev->coupled;
> +
> + if (cpumask_empty(&dev->coupled_cpus))
> + return;
> +
> + if (--coupled->refcnt)
> + kfree(coupled);
> + dev->coupled = NULL;
> +}
> +
> +/**
> + * cpuidle_coupled_cpu_set_alive - adjust alive_count during hotplug transitions
> + * @cpu: target cpu number
> + * @alive: whether the target cpu is going up or down
> + *
> + * Run on the cpu that is bringing up the target cpu, before the target cpu
> + * has been booted, or after the target cpu is completely dead.
> + */
> +static void cpuidle_coupled_cpu_set_alive(int cpu, bool alive)
> +{
> + struct cpuidle_device *dev;
> + struct cpuidle_coupled *coupled;
> +
> + mutex_lock(&cpuidle_lock);
> +
> + dev = per_cpu(cpuidle_devices, cpu);
> + if (!dev->coupled)
> + goto out;
> +
> + coupled = dev->coupled;
> +
> + /*
> + * waiting_count must be at least 1 less than alive_count, because
> + * this cpu is not waiting. Spin until all cpus have noticed this cpu
> + * is not idle and exited the ready loop before changing alive_count.
> + */
> + while (atomic_read(&coupled->ready_count))
> + cpu_relax();
> +
> + if (alive) {
> + smp_mb__before_atomic_inc();
> + atomic_inc(&coupled->alive_count);
> + smp_mb__after_atomic_inc();
> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_NOT_IDLE;
> + } else {
> + smp_mb__before_atomic_dec();
> + atomic_dec(&coupled->alive_count);
> + smp_mb__after_atomic_dec();
> + coupled->requested_state[dev->cpu] = CPUIDLE_COUPLED_DEAD;
There's too many SMP barriers above, but I'm not quite sure which of them (if
any) are really necessary.
> + }
> +
> +out:
> + mutex_unlock(&cpuidle_lock);
> +}
> +
> +/**
> + * cpuidle_coupled_cpu_notify - notifier called during hotplug transitions
> + * @nb: notifier block
> + * @action: hotplug transition
> + * @hcpu: target cpu number
> + *
> + * Called when a cpu is brought on or offline using hotplug. Updates the
> + * coupled cpu set appropriately
> + */
> +static int cpuidle_coupled_cpu_notify(struct notifier_block *nb,
> + unsigned long action, void *hcpu)
> +{
> + int cpu = (unsigned long)hcpu;
> +
> + switch (action & ~CPU_TASKS_FROZEN) {
> + case CPU_DEAD:
> + case CPU_UP_CANCELED:
> + cpuidle_coupled_cpu_set_alive(cpu, false);
> + break;
> + case CPU_UP_PREPARE:
> + cpuidle_coupled_cpu_set_alive(cpu, true);
> + break;
> + }
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block cpuidle_coupled_cpu_notifier = {
> + .notifier_call = cpuidle_coupled_cpu_notify,
> +};
> +
> +static int __init cpuidle_coupled_init(void)
> +{
> + return register_cpu_notifier(&cpuidle_coupled_cpu_notifier);
> +}
> +core_initcall(cpuidle_coupled_init);
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 4540672..e81cfda 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -171,7 +171,11 @@ int cpuidle_idle_call(void)
> trace_power_start_rcuidle(POWER_CSTATE, next_state, dev->cpu);
> trace_cpu_idle_rcuidle(next_state, dev->cpu);
>
> - entered_state = cpuidle_enter_state(dev, drv, next_state);
> + if (cpuidle_state_is_coupled(dev, drv, next_state))
> + entered_state = cpuidle_enter_state_coupled(dev, drv,
> + next_state);
> + else
> + entered_state = cpuidle_enter_state(dev, drv, next_state);
>
> trace_power_end_rcuidle(dev->cpu);
> trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
> @@ -407,9 +411,16 @@ static int __cpuidle_register_device(struct cpuidle_device *dev)
> if (ret)
> goto err_sysfs;
>
> + ret = cpuidle_coupled_register_device(dev);
> + if (ret)
> + goto err_coupled;
> +
> dev->registered = 1;
> return 0;
>
> +err_coupled:
> + cpuidle_remove_sysfs(cpu_dev);
> + wait_for_completion(&dev->kobj_unregister);
> err_sysfs:
> list_del(&dev->device_list);
> per_cpu(cpuidle_devices, dev->cpu) = NULL;
> @@ -464,6 +475,8 @@ void cpuidle_unregister_device(struct cpuidle_device *dev)
> wait_for_completion(&dev->kobj_unregister);
> per_cpu(cpuidle_devices, dev->cpu) = NULL;
>
> + cpuidle_coupled_unregister_device(dev);
> +
> cpuidle_resume_and_unlock();
>
> module_put(cpuidle_driver->owner);
> diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
> index d8a3ccc..76e7f69 100644
> --- a/drivers/cpuidle/cpuidle.h
> +++ b/drivers/cpuidle/cpuidle.h
> @@ -32,4 +32,34 @@ extern int cpuidle_enter_state(struct cpuidle_device *dev,
> extern int cpuidle_add_sysfs(struct device *dev);
> extern void cpuidle_remove_sysfs(struct device *dev);
>
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> +bool cpuidle_state_is_coupled(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int state);
> +int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int next_state);
> +int cpuidle_coupled_register_device(struct cpuidle_device *dev);
> +void cpuidle_coupled_unregister_device(struct cpuidle_device *dev);
> +#else
> +static inline bool cpuidle_state_is_coupled(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int state)
> +{
> + return false;
> +}
> +
> +static inline int cpuidle_enter_state_coupled(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int next_state)
> +{
> + return -1;
> +}
> +
> +static inline int cpuidle_coupled_register_device(struct cpuidle_device *dev)
> +{
> + return 0;
> +}
> +
> +static inline void cpuidle_coupled_unregister_device(struct cpuidle_device *dev)
> +{
> +}
> +#endif
> +
> #endif /* __DRIVER_CPUIDLE_H */
> diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
> index 6c26a3d..6038448 100644
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -57,6 +57,7 @@ struct cpuidle_state {
>
> /* Idle State Flags */
> #define CPUIDLE_FLAG_TIME_VALID (0x01) /* is residency time measurable? */
> +#define CPUIDLE_FLAG_COUPLED (0x02) /* state applies to multiple cpus */
>
> #define CPUIDLE_DRIVER_FLAGS_MASK (0xFFFF0000)
>
> @@ -100,6 +101,12 @@ struct cpuidle_device {
> struct list_head device_list;
> struct kobject kobj;
> struct completion kobj_unregister;
> +
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
> + int safe_state_index;
> + cpumask_t coupled_cpus;
> + struct cpuidle_coupled *coupled;
> +#endif
> };
>
> DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCHv3 5/5] cpuidle: coupled: add trace events
From: Colin Cross @ 2012-05-03 21:13 UTC (permalink / raw)
To: Steven Rostedt
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <1336078827.14207.109.camel@gandalf.stny.rr.com>
On Thu, May 3, 2012 at 2:00 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 2012-04-30 at 13:09 -0700, Colin Cross wrote:
>
>> diff --git a/include/trace/events/cpuidle.h b/include/trace/events/cpuidle.h
>> new file mode 100644
>> index 0000000..9b2cbbb
>> --- /dev/null
>> +++ b/include/trace/events/cpuidle.h
>> @@ -0,0 +1,243 @@
>> +#undef TRACE_SYSTEM
>> +#define TRACE_SYSTEM cpuidle
>> +
>> +#if !defined(_TRACE_CPUIDLE_H) || defined(TRACE_HEADER_MULTI_READ)
>> +#define _TRACE_CPUIDLE_H
>> +
>> +#include <linux/atomic.h>
>> +#include <linux/tracepoint.h>
>> +
>> +extern atomic_t cpuidle_trace_seq;
>> +
>> +TRACE_EVENT(coupled_enter,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_exit,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_spin,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_unspin,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_safe_enter,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_safe_exit,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_idle_enter,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_idle_exit,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_abort,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_detected_abort,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_poke,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>> +
>> +TRACE_EVENT(coupled_poked,
>> +
>> + TP_PROTO(unsigned int cpu),
>> +
>> + TP_ARGS(cpu),
>> +
>> + TP_STRUCT__entry(
>> + __field(unsigned int, cpu)
>> + __field(unsigned int, seq)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->cpu = cpu;
>> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
>> + ),
>> +
>> + TP_printk("%u %u", __entry->seq, __entry->cpu)
>> +);
>
> Egad! Please use DECLARE_EVENT_CLASS() and DEFINE_EVENT() when adding
> events that are basically the same. Every TRACE_EVENT() can bloat the
> kernel by 5k, using the DEFINE_EVENT()s keeps each event around just a
> few hundred bytes.
>
> See include/trace/events/ext4.h for examples.
Thanks, I'll take a look. There is no mention in Documentation/ or
samples/ of DECLARE_EVENT_CLASS() or DEFINE_EVENT(), nor any mention
of the cost of TRACE_EVENT().
Looking at the new power tracing code, I will also rework these events
to be more similar to the existing ones.
I suggest skipping this patch for 3.5, and I'll post an updated one for 3.6.
^ permalink raw reply
* Re: [PATCHv3 5/5] cpuidle: coupled: add trace events
From: Steven Rostedt @ 2012-05-03 21:00 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <1335816551-27756-6-git-send-email-ccross@android.com>
On Mon, 2012-04-30 at 13:09 -0700, Colin Cross wrote:
> diff --git a/include/trace/events/cpuidle.h b/include/trace/events/cpuidle.h
> new file mode 100644
> index 0000000..9b2cbbb
> --- /dev/null
> +++ b/include/trace/events/cpuidle.h
> @@ -0,0 +1,243 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM cpuidle
> +
> +#if !defined(_TRACE_CPUIDLE_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_CPUIDLE_H
> +
> +#include <linux/atomic.h>
> +#include <linux/tracepoint.h>
> +
> +extern atomic_t cpuidle_trace_seq;
> +
> +TRACE_EVENT(coupled_enter,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_exit,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_spin,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_unspin,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_safe_enter,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_safe_exit,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_idle_enter,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_idle_exit,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_abort,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_detected_abort,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_poke,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
> +
> +TRACE_EVENT(coupled_poked,
> +
> + TP_PROTO(unsigned int cpu),
> +
> + TP_ARGS(cpu),
> +
> + TP_STRUCT__entry(
> + __field(unsigned int, cpu)
> + __field(unsigned int, seq)
> + ),
> +
> + TP_fast_assign(
> + __entry->cpu = cpu;
> + __entry->seq = atomic_inc_return(&cpuidle_trace_seq);
> + ),
> +
> + TP_printk("%u %u", __entry->seq, __entry->cpu)
> +);
Egad! Please use DECLARE_EVENT_CLASS() and DEFINE_EVENT() when adding
events that are basically the same. Every TRACE_EVENT() can bloat the
kernel by 5k, using the DEFINE_EVENT()s keeps each event around just a
few hundred bytes.
See include/trace/events/ext4.h for examples.
-- Steve
> +
> +#endif /* if !defined(_TRACE_CPUIDLE_H) || defined(TRACE_HEADER_MULTI_READ) */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
^ permalink raw reply
* Re: [PATCHv3 2/5] cpuidle: fix error handling in __cpuidle_register_device
From: Rafael J. Wysocki @ 2012-05-03 20:50 UTC (permalink / raw)
To: linux-pm
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, Colin Cross,
Arnd Bergmann, Arjan van de Ven, linux-arm-kernel
In-Reply-To: <1335816551-27756-3-git-send-email-ccross@android.com>
On Monday, April 30, 2012, Colin Cross wrote:
> Fix the error handling in __cpuidle_register_device to include
> the missing list_del. Move it to a label, which will simplify
> the error handling when coupled states are added.
>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> Tested-by: Kevin Hilman <khilman@ti.com>
> Signed-off-by: Colin Cross <ccross@android.com>
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
> drivers/cpuidle/cpuidle.c | 13 +++++++++----
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 3e3e3e4..4540672 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -403,13 +403,18 @@ static int __cpuidle_register_device(struct cpuidle_device *dev)
>
> per_cpu(cpuidle_devices, dev->cpu) = dev;
> list_add(&dev->device_list, &cpuidle_detected_devices);
> - if ((ret = cpuidle_add_sysfs(cpu_dev))) {
> - module_put(cpuidle_driver->owner);
> - return ret;
> - }
> + ret = cpuidle_add_sysfs(cpu_dev);
> + if (ret)
> + goto err_sysfs;
>
> dev->registered = 1;
> return 0;
> +
> +err_sysfs:
> + list_del(&dev->device_list);
> + per_cpu(cpuidle_devices, dev->cpu) = NULL;
> + module_put(cpuidle_driver->owner);
> + return ret;
> }
>
> /**
>
^ permalink raw reply
* Re: [PATCHv3 1/5] cpuidle: refactor out cpuidle_enter_state
From: Rafael J. Wysocki @ 2012-05-03 20:50 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <1335816551-27756-2-git-send-email-ccross@android.com>
On Monday, April 30, 2012, Colin Cross wrote:
> Split the code to enter a state and update the stats into a helper
> function, cpuidle_enter_state, and export it. This function will
> be called by the coupled state code to handle entering the safe
> state and the final coupled state.
>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> Tested-by: Kevin Hilman <khilman@ti.com>
> Signed-off-by: Colin Cross <ccross@android.com>
Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
> drivers/cpuidle/cpuidle.c | 42 +++++++++++++++++++++++++++++-------------
> drivers/cpuidle/cpuidle.h | 2 ++
> 2 files changed, 31 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 2f0083a..3e3e3e4 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -103,6 +103,34 @@ int cpuidle_play_dead(void)
> }
>
> /**
> + * cpuidle_enter_state - enter the state and update stats
> + * @dev: cpuidle device for this cpu
> + * @drv: cpuidle driver for this cpu
> + * @next_state: index into drv->states of the state to enter
> + */
> +int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver *drv,
> + int next_state)
> +{
> + int entered_state;
> +
> + entered_state = cpuidle_enter_ops(dev, drv, next_state);
> +
> + if (entered_state >= 0) {
> + /* Update cpuidle counters */
> + /* This can be moved to within driver enter routine
> + * but that results in multiple copies of same code.
> + */
> + dev->states_usage[entered_state].time +=
> + (unsigned long long)dev->last_residency;
> + dev->states_usage[entered_state].usage++;
> + } else {
> + dev->last_residency = 0;
> + }
> +
> + return entered_state;
> +}
> +
> +/**
> * cpuidle_idle_call - the main idle loop
> *
> * NOTE: no locks or semaphores should be used here
> @@ -143,23 +171,11 @@ int cpuidle_idle_call(void)
> trace_power_start_rcuidle(POWER_CSTATE, next_state, dev->cpu);
> trace_cpu_idle_rcuidle(next_state, dev->cpu);
>
> - entered_state = cpuidle_enter_ops(dev, drv, next_state);
> + entered_state = cpuidle_enter_state(dev, drv, next_state);
>
> trace_power_end_rcuidle(dev->cpu);
> trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, dev->cpu);
>
> - if (entered_state >= 0) {
> - /* Update cpuidle counters */
> - /* This can be moved to within driver enter routine
> - * but that results in multiple copies of same code.
> - */
> - dev->states_usage[entered_state].time +=
> - (unsigned long long)dev->last_residency;
> - dev->states_usage[entered_state].usage++;
> - } else {
> - dev->last_residency = 0;
> - }
> -
> /* give the governor an opportunity to reflect on the outcome */
> if (cpuidle_curr_governor->reflect)
> cpuidle_curr_governor->reflect(dev, entered_state);
> diff --git a/drivers/cpuidle/cpuidle.h b/drivers/cpuidle/cpuidle.h
> index 7db1866..d8a3ccc 100644
> --- a/drivers/cpuidle/cpuidle.h
> +++ b/drivers/cpuidle/cpuidle.h
> @@ -14,6 +14,8 @@
> extern struct mutex cpuidle_lock;
> extern spinlock_t cpuidle_driver_lock;
> extern int cpuidle_disabled(void);
> +extern int cpuidle_enter_state(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv, int next_state);
>
> /* idle loop */
> extern void cpuidle_install_idle_handler(void);
>
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Rafael J. Wysocki @ 2012-05-03 20:43 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <CAMbhsRS8D=d9aAbikosOis+Q+jMU04Oj9xaRg0jMVxtQ7nijTw@mail.gmail.com>
On Thursday, May 03, 2012, Colin Cross wrote:
> On Thu, May 3, 2012 at 1:00 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> <snip>
> > There are two distinct cases to consider here, (1) when the last I/O
> > device in the domain becomes idle and the question is whether or not to
> > power off the entire domain and (2) when a CPU core in a power domain
> > becomes idle while all of the devices in the domain are idle already.
> >
> > Case (2) is quite straightforward, the .enter() routine for the
> > "domain" C-state has to check whether the domain can be turned off and
> > do it eventually.
> >
> > Case (1) is more difficult and (assuming that all CPU cores in the domain
> > are already idle at this point) i see two possible ways to handle it:
> > (a) Wake up all of the (idle) CPU cores in the domain and let the
> > "domain" C-state's .enter() do the job (ie. turn it into case (2)),
> > similarly to your patchset.
> > (b) If cpuidle has prepared the cores for going into deeper idle,
> > turn the domain off directly without waking up the cores.
>
> Multiple clusters is a design that has been considered in this
> patchset (all the data structures are in the right place to support
> it), and can be supported in the future, but does not exist in any
> current systems that would be using this. In all of today's SoCs,
> there is a single cluster, so (1) can't happen - no code can be
> executing while all cpus are idle.
OK, but I think it should be taken into consideration nonetheless.
> (b) is an optimization that would not be possible on any future SoC
> that is similar to the current SoCs, where "turn the domain off" is
> very tightly integrated with TrustZone secure code running on the
> primary cpu of the cluster.
I see.
> <snip>
>
> > Having considered this for a while I think that it may be more straightforward
> > to avoid waking up the already idled cores.
> >
> > For instance, say we have 4 CPU cores in a cluster (package) such that each
> > core has its own idle state (call it C1) and there is a multicore idle state
> > entered by turning off the entire cluster (call this state C-multi). One of
> > the possible ways to handle this seems to be to use an identical table of
> > C-states for each core containing the C1 entry and a kind of fake entry called
> > (for example) C4 with the time characteristics of C-multi and a special
> > .enter() callback. That callback will prepare the core it is called for to
> > enter C-multi, but instead of simply turning off the whole package it will
> > decrement a counter. If the counte happens to be 0 at this point, the
> > package will be turned off. Otherwise, the core will be put into the idle
> > state corresponding to C1, but it will be ready for entering C-multi at
> > any time. The counter will be incremented on exiting the C4 "state".
>
> I implemented something very similar to this on Tegra2 (having each
> cpu go to C1, but with enough state saved for C-multi), but it turns
> out not to work in hardware. On every existing ARM SMP system where I
> have worked with cpuidle (Tegra2, OMAP4, Exynos5, and some Tegra3),
> only cpu 0 can trigger the transition to C-multi. The cause of this
> restriction is different on every platform - sometimes it's by design,
> sometimes it's a bug in the SoC ROM code, but the restriction exists.
> The primary cpu of the cluster always needs to be awake.
OK, so that means we need to do the wakeup for technical reasons.
> In addition, it may not be possible to transition secondary cpus from
> C1 to C-multi without waking them. That would generally involve
> cutting power to a CPU that is in clock gating, which is not a
> supported power transition in any SoC that I have a datasheet for. I
> made it work for cpu1 on Tegra2, but I can't guarantee that there are
> not unsolvable HW race conditions.
>
> The only generic way to make this work is to wake up all cpus. Waking
> up a subset of cpus is certainly worth investigating as an
> optimization, but it would not be used on Tegra2, OMAP4, or Exynos5.
> Tegra3 may benefit from it.
OK
> > It looks like this should work without modifying the cpuidle core, but
> > the drawback here is that the cpuidle core doesn't know how much time
> > spend in C4 is really in C1 and how much of it is in C-multi, so the
> > statistics reported by it won't reflect the real energy usage.
>
> Idle statistics are extremely important when determining why a
> particular use case is drawing too much power, and it is worth
> modifying the cpuidle core if only to keep them accurate. Especially
> when justifying the move from the cpufreq hotplug governor based code
> that every SoC vendor uses in their BSP to a proper multi-CPU cpuidle
> implementation.
I see.
Thanks for the explanation,
Rafael
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Colin Cross @ 2012-05-03 20:18 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <201205032200.01823.rjw@sisk.pl>
On Thu, May 3, 2012 at 1:00 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
<snip>
> There are two distinct cases to consider here, (1) when the last I/O
> device in the domain becomes idle and the question is whether or not to
> power off the entire domain and (2) when a CPU core in a power domain
> becomes idle while all of the devices in the domain are idle already.
>
> Case (2) is quite straightforward, the .enter() routine for the
> "domain" C-state has to check whether the domain can be turned off and
> do it eventually.
>
> Case (1) is more difficult and (assuming that all CPU cores in the domain
> are already idle at this point) i see two possible ways to handle it:
> (a) Wake up all of the (idle) CPU cores in the domain and let the
> "domain" C-state's .enter() do the job (ie. turn it into case (2)),
> similarly to your patchset.
> (b) If cpuidle has prepared the cores for going into deeper idle,
> turn the domain off directly without waking up the cores.
Multiple clusters is a design that has been considered in this
patchset (all the data structures are in the right place to support
it), and can be supported in the future, but does not exist in any
current systems that would be using this. In all of today's SoCs,
there is a single cluster, so (1) can't happen - no code can be
executing while all cpus are idle.
(b) is an optimization that would not be possible on any future SoC
that is similar to the current SoCs, where "turn the domain off" is
very tightly integrated with TrustZone secure code running on the
primary cpu of the cluster.
<snip>
> Having considered this for a while I think that it may be more straightforward
> to avoid waking up the already idled cores.
>
> For instance, say we have 4 CPU cores in a cluster (package) such that each
> core has its own idle state (call it C1) and there is a multicore idle state
> entered by turning off the entire cluster (call this state C-multi). One of
> the possible ways to handle this seems to be to use an identical table of
> C-states for each core containing the C1 entry and a kind of fake entry called
> (for example) C4 with the time characteristics of C-multi and a special
> .enter() callback. That callback will prepare the core it is called for to
> enter C-multi, but instead of simply turning off the whole package it will
> decrement a counter. If the counte happens to be 0 at this point, the
> package will be turned off. Otherwise, the core will be put into the idle
> state corresponding to C1, but it will be ready for entering C-multi at
> any time. The counter will be incremented on exiting the C4 "state".
I implemented something very similar to this on Tegra2 (having each
cpu go to C1, but with enough state saved for C-multi), but it turns
out not to work in hardware. On every existing ARM SMP system where I
have worked with cpuidle (Tegra2, OMAP4, Exynos5, and some Tegra3),
only cpu 0 can trigger the transition to C-multi. The cause of this
restriction is different on every platform - sometimes it's by design,
sometimes it's a bug in the SoC ROM code, but the restriction exists.
The primary cpu of the cluster always needs to be awake.
In addition, it may not be possible to transition secondary cpus from
C1 to C-multi without waking them. That would generally involve
cutting power to a CPU that is in clock gating, which is not a
supported power transition in any SoC that I have a datasheet for. I
made it work for cpu1 on Tegra2, but I can't guarantee that there are
not unsolvable HW race conditions.
The only generic way to make this work is to wake up all cpus. Waking
up a subset of cpus is certainly worth investigating as an
optimization, but it would not be used on Tegra2, OMAP4, or Exynos5.
Tegra3 may benefit from it.
> It looks like this should work without modifying the cpuidle core, but
> the drawback here is that the cpuidle core doesn't know how much time
> spend in C4 is really in C1 and how much of it is in C-multi, so the
> statistics reported by it won't reflect the real energy usage.
Idle statistics are extremely important when determining why a
particular use case is drawing too much power, and it is worth
modifying the cpuidle core if only to keep them accurate. Especially
when justifying the move from the cpufreq hotplug governor based code
that every SoC vendor uses in their BSP to a proper multi-CPU cpuidle
implementation.
^ permalink raw reply
* Re: [PATCHv3 0/5] coupled cpuidle state support
From: Rafael J. Wysocki @ 2012-05-03 20:00 UTC (permalink / raw)
To: Colin Cross
Cc: Kevin Hilman, Len Brown, Russell King, Greg Kroah-Hartman,
Kay Sievers, linux-kernel, Amit Kucheria, linux-pm,
Arjan van de Ven, Arnd Bergmann, linux-arm-kernel
In-Reply-To: <CAMbhsRQcDDW5vWbqb1FRtvOmq6UjOjXj9MCfSt2KF9fHrcY59Q@mail.gmail.com>
On Tuesday, May 01, 2012, Colin Cross wrote:
> On Mon, Apr 30, 2012 at 2:54 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Monday, April 30, 2012, Colin Cross wrote:
> >> On Mon, Apr 30, 2012 at 2:25 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > Hi,
> >> >
> >> > I have a comment, which isn't about the series itself, but something
> >> > thay may be worth thinking about.
> >> >
> >> > On Monday, April 30, 2012, Colin Cross wrote:
> >> >> On some ARM SMP SoCs (OMAP4460, Tegra 2, and probably more), the
> >> >> cpus cannot be independently powered down, either due to
> >> >> sequencing restrictions (on Tegra 2, cpu 0 must be the last to
> >> >> power down), or due to HW bugs (on OMAP4460, a cpu powering up
> >> >> will corrupt the gic state unless the other cpu runs a work
> >> >> around). Each cpu has a power state that it can enter without
> >> >> coordinating with the other cpu (usually Wait For Interrupt, or
> >> >> WFI), and one or more "coupled" power states that affect blocks
> >> >> shared between the cpus (L2 cache, interrupt controller, and
> >> >> sometimes the whole SoC). Entering a coupled power state must
> >> >> be tightly controlled on both cpus.
> >> >
> >> > That seems to be a special case of a more general situation where
> >> > a number of CPU cores belong into a single power domain, possibly along
> >> > some I/O devices.
> >> >
> >> > We'll need to handle the general case at one point anyway, so I wonder if
> >> > the approach shown here may get us in the way?
> >>
> >> I can't parse what you're saying here.
> >
> > The general case is a CPU core in one PM domain with a number of I/O
> > devices and a number of other CPU cores. If we forget about the I/O
> > devices, we get a situation your patchset is addressing, so the
> > question is how difficult it is going to be to extend it to cover the
> > I/O devices as well.
>
> The logic in this patch set is always going to be required to get
> multiple cpus to coordinate an idle transition, and it will need to
> stay fairly tightly coupled with cpuidle to correctly track the idle
> time statistics for the intermediate and final states. I don't think
> there would be an issue if it ends up getting hoisted out into a
> future combined cpu/IO power domain, but it seems more likely that the
> coupled cpu idle states would call into the power domain to say they
> no longer need power.
There are two distinct cases to consider here, (1) when the last I/O
device in the domain becomes idle and the question is whether or not to
power off the entire domain and (2) when a CPU core in a power domain
becomes idle while all of the devices in the domain are idle already.
Case (2) is quite straightforward, the .enter() routine for the
"domain" C-state has to check whether the domain can be turned off and
do it eventually.
Case (1) is more difficult and (assuming that all CPU cores in the domain
are already idle at this point) i see two possible ways to handle it:
(a) Wake up all of the (idle) CPU cores in the domain and let the
"domain" C-state's .enter() do the job (ie. turn it into case (2)),
similarly to your patchset.
(b) If cpuidle has prepared the cores for going into deeper idle,
turn the domain off directly without waking up the cores.
> >> >> The easiest solution to implementing coupled cpu power states is
> >> >> to hotplug all but one cpu whenever possible, usually using a
> >> >> cpufreq governor that looks at cpu load to determine when to
> >> >> enable the secondary cpus. This causes problems, as hotplug is an
> >> >> expensive operation, so the number of hotplug transitions must be
> >> >> minimized, leading to very slow response to loads, often on the
> >> >> order of seconds.
> >> >
> >> > This isn't a solution at all, rather a workaround and a poor one for that
> >> > matter.
> >>
> >> Yes, which is what started me on this series.
> >>
> >> >> This patch series implements an alternative solution, where each
> >> >> cpu will wait in the WFI state until all cpus are ready to enter
> >> >> a coupled state, at which point the coupled state function will
> >> >> be called on all cpus at approximately the same time.
> >> >>
> >> >> Once all cpus are ready to enter idle, they are woken by an smp
> >> >> cross call.
> >> >
> >> > Is it really necessary to wake up all of the CPUs in WFI before
> >> > going to deeper idle? We should be able to figure out when they
> >> > are going to be needed next time without waking them up and we should
> >> > know the latency to wake up from the deeper multi-CPU "C-state",
> >> > so it should be possible to decide whether or not to go to deeper
> >> > idle without the SMP cross call. Is there anything I'm missing here?
> >>
> >> The decision to go to the lower state has already been made when the
> >> cross call occurs. On the platforms I have worked directly with so
> >> far (Tegra2 and OMAP4460), the secondary cpu needs to execute code
> >> before the primary cpu turns off the power. For example, on OMAP4460,
> >> the secondary cpu needs to go from WFI (clock gated) to OFF (power
> >> gated), because OFF is not supported as an individual cpu state due to
> >> a ROM code bug. To do that transition, it needs to come out of WFI,
> >> set up it's power domain registers, save a bunch of state, and
> >> transition to OFF.
> >>
> >> On Tegra3, the deepest individual cpu state for cpus 1-3 is OFF, the
> >> same state the cpu would go into as the first step of a transition to
> >> a deeper power state (cpus 0-3 OFF). It would be more optimal in that
> >> case to bypass the SMP cross call, and leave the cpu in OFF, but that
> >> would require some way of disabling all wakeups for the secondary cpus
> >> and then verifying that they didn't start waking up just before the
> >> wakeups were disabled. I have just started considering this
> >> optimization, but I don't see anything in the existing code that would
> >> prevent adding it later.
> >
> > OK
> >
> >> A simple measurement using the tracing may show that it is
> >> unnecessary. If the wakeup time for CPU1 to go from OFF to active is
> >> small there might be no need to optimize out the extra wakeup.
> >
> > I see.
> >
> > So, in the end, it may always be more straightforward to put individual
> > CPU cores into single-core idle states until the "we can all go to
> > deeper idle" condition is satisfied and then wake them all up and let
> > each of them do the transition individually, right?
>
> Yes, the tradeoff will be the complexity of code to handle a generic
> way of holding another cpu in idle while this cpu does the transition
> vs. the time and power required to bring a cpu back online just to put
> it into a deeper state. Right now, since all the users of this code
> are using WFI for their intermediate state, it takes microseconds to
> bring a cpu back up. On Tegra3, the answer might be "sometimes" -
> only cpu0 can perform the final idle state transition, so if cpu1 is
> the last to go to idle, it will always have to SMP cross call to cpu0,
> but if cpu0 is the last to go idle it may be able to avoid waking up
> cpu1.
Having considered this for a while I think that it may be more straightforward
to avoid waking up the already idled cores.
For instance, say we have 4 CPU cores in a cluster (package) such that each
core has its own idle state (call it C1) and there is a multicore idle state
entered by turning off the entire cluster (call this state C-multi). One of
the possible ways to handle this seems to be to use an identical table of
C-states for each core containing the C1 entry and a kind of fake entry called
(for example) C4 with the time characteristics of C-multi and a special
.enter() callback. That callback will prepare the core it is called for to
enter C-multi, but instead of simply turning off the whole package it will
decrement a counter. If the counte happens to be 0 at this point, the
package will be turned off. Otherwise, the core will be put into the idle
state corresponding to C1, but it will be ready for entering C-multi at
any time. The counter will be incremented on exiting the C4 "state".
It looks like this should work without modifying the cpuidle core, but
the drawback here is that the cpuidle core doesn't know how much time
spend in C4 is really in C1 and how much of it is in C-multi, so the
statistics reported by it won't reflect the real energy usage.
Thanks,
Rafael
^ permalink raw reply
* [PATCH 1/1] battery: only refresh the sysfs files when pertinant information changes
From: Andy Whitcroft @ 2012-05-03 13:48 UTC (permalink / raw)
To: Matthew Garrett, Rafael J. Wysocki, Jonathan Nieder
Cc: Andy Whitcroft, ACPI Devel Maling List, Linux-pm mailing list,
Adrian Fita, Len Brown, Ralf Jung, Paolo Scarabelli, linux-kernel
In-Reply-To: <20120503124708.GA18622@srcf.ucam.org>
We only need to regenerate the sysfs files when the capacity units
change, avoid the update otherwise.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
---
drivers/acpi/battery.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
Based on Matthew's feedback here is a version which optimises
based on the power_unit field as returned from the battery info.
Could someone who suffers from this issue please test this out
and report back. Thanks.
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 86933ca..7dd3f9f 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -643,11 +643,19 @@ static int acpi_battery_update(struct acpi_battery *battery)
static void acpi_battery_refresh(struct acpi_battery *battery)
{
+ int power_unit;
+
if (!battery->bat.dev)
return;
+ power_unit = battery->power_unit;
+
acpi_battery_get_info(battery);
- /* The battery may have changed its reporting units. */
+
+ if (power_unit == battery->power_unit)
+ return;
+
+ /* The battery has changed its reporting units. */
sysfs_remove_battery(battery);
sysfs_add_battery(battery);
}
--
1.7.9.5
^ permalink raw reply related
* Re: [bug?] Battery notifications produce flashing battery icon, syslog spam (Re: [PATCH 11/11] ACPI / Battery: Update information on info notification and resume)
From: Matthew Garrett @ 2012-05-03 12:47 UTC (permalink / raw)
To: Andy Whitcroft
Cc: Jonathan Nieder, Adrian Fita, Rafael J. Wysocki, Len Brown, LKML,
ACPI Devel Maling List, Linux-pm mailing list, Ralf Jung,
Paolo Scarabelli
In-Reply-To: <20120503085458.GG3364@shadowen.org>
On Thu, May 03, 2012 at 09:54:58AM +0100, Andy Whitcroft wrote:
>
> From the description of the change this is necessary because the
> capacity units may change over time? Can we not use those to avoid this
> update? I presume it is these two we are referring to?
>
> int capacity_granularity_1;
> int capacity_granularity_2;
power_unit rather than capacity_granularity, but the idea seems solid.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [bug?] Battery notifications produce flashing battery icon, syslog spam (Re: [PATCH 11/11] ACPI / Battery: Update information on info notification and resume)
From: Andy Whitcroft @ 2012-05-03 8:54 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Adrian Fita, Rafael J. Wysocki, Len Brown, LKML, Matthew Garrett,
ACPI Devel Maling List, Linux-pm mailing list, Ralf Jung,
Paolo Scarabelli
In-Reply-To: <20120501191408.GD19143@burratino>
On Tue, May 01, 2012 at 02:14:08PM -0500, Jonathan Nieder wrote:
> (cc-ing Andy)
> Adrian Fita wrote:
>
> > Also, searching on Google after "upowerd device
> > removed:/org/freedesktop/UPower/devices/battery_BAT0", reveals much
> > more bug reports with the exact issue.
>
> Thanks. That confirms the high CPU consumption in upowerd ---
> see [1], for example.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/987807
It does seem somewhat heavyweight to be removing and reinstalling all of
the sysfs files every time we get one of these events. I am assuming
here that some BIOSs are using this interface to tell us the batery
capacity has changed and triggering the constant add/remove of the
devices and associated flickering.
>From the description of the change this is necessary because the
capacity units may change over time? Can we not use those to avoid this
update? I presume it is these two we are referring to?
int capacity_granularity_1;
int capacity_granularity_2;
If those are unchanged perhaps we can just skip the update? Something
like the below (completly untested, for discussion).
Thoughts?
-apw
commit d558d0c38e26e2c7eae68d19f4d2fa3ecd8e31f2
Author: Andy Whitcroft <apw@canonical.com>
Date: Thu May 3 09:52:28 2012 +0100
battery: only refresh the sysfs files when pertinant information changes
We only need to regenerate the sysfs files when the capacity units
change, avoid the update otherwise.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index eb18c44..f8d37b4 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -643,10 +643,20 @@ static int acpi_battery_update(struct acpi_battery *battery)
static void acpi_battery_refresh(struct acpi_battery *battery)
{
+ int cg1, cg2;
+
if (!battery->bat.dev)
return;
+ cg1 = battery->capacity_granularity_1;
+ cg2 = battery->capacity_granularity_2;
+
acpi_battery_get_info(battery);
+
+ if (cg1 == battery->capacity_granularity_1 &&
+ cg2 == capacity_granularity_2)
+ return;
+
/* The battery may have changed its reporting units. */
sysfs_remove_battery(battery);
sysfs_add_battery(battery);
^ permalink raw reply related
* Plumbers: PM constraints micro-conf RFP
From: mark gross @ 2012-05-02 14:36 UTC (permalink / raw)
To: mark gross, John Stultz, jeen.pihet, MyungJoo Ham, Amit Kucheria,
Agarwal, Ramesh, Praveen Chidambaram, Antti P Miettinen,
Valentin, Eduardo, Rafael J. Wysocki, Kevin Hilman
Cc: paulmck, linux-pm
This is a Request For Participation in a micro-conference at this years
Linux plumbers event. For this micro conference to happen we need to
reach a certain critical mass WRT participants as measured by submitted
talks associated to Power Management Constraints.
The To: list is populated with folks that I've had interactions with
over extending pm-qos or constraint based PM over the past year.
If you are working on problems related to constraining the power /
performance of devices I am inviting your participation and request you
submit a proposal for presenting your problem space (preferred) and or
solution to a group of developers looking for a good solution to push
upstream. The talks will be about 20 min long as I want to get into
some design and implementation discussions after the requirements
definition is mostly finished.
I am interested in gathering user mode interface needs as well as kernel
mode.
>From a high level pm-constraints is a generalization of pm-qos to include
limiting performance as well as its current limiting of device
throttling.
As performance limiting is typically used for any of the following:
1) staying within thermal operational envelopes
2) avoiding peak current
3) extending battery life in active use cases
I invite anyone working in any of these areas or pm-qos applications to
participate in this micro-conference.
I will organize the micro-conference into 2 parts:
1) problem statements with specific participant examples where
constraining the performance or throttling is needed.
2) high level design brain storming.
If the micro-conference happens (i.e. critical mass is reached) any
interested linux-plumbers attendees is very welcome to participate.
Please send me an off list email if you want me to add you to my mutt
alias of interested parties I'll use to cc people on emails. Note: must
of the correspondence will cc linux-pm too.
Please submit a proposal if you are interested in participating in this
with me. I know a number of people are working in this space for the
past few years now. I think its a good time to compare notes and at
least consolidate requirements and use cases. Perhaps we'll even come up
with a good design to implement in the process.
thanks,
--mark
^ permalink raw reply
* Re: [bug?] Battery notifications produce flashing battery icon, syslog spam (Re: [PATCH 11/11] ACPI / Battery: Update information on info notification and resume)
From: Paolo Scarabelli @ 2012-05-02 11:49 UTC (permalink / raw)
To: Ralf Jung
Cc: Jonathan Nieder, Adrian Fita, Rafael J. Wysocki, Len Brown, LKML,
Matthew Garrett, ACPI Devel Maling List, Linux-pm mailing list,
Andy Whitcroft
In-Reply-To: <201205012142.55664.post@ralfj.de>
Hi,
I have the same problem on kernel 3.2.0 (actually I have the same
problem with all kernels I tried since reporting the issue the first time).
I'm almost sure this is related to several Debian bugs open for upower:
#606414, #596721 and #619343.
Is it possible that the high cpu problem with upowerd is caused just to
the log size increasing too much when the laptop is left on for a long time?
In my laptop upowerd starts using a lot of cpu only when I leave it on
overnight.
Regards,
Paolo
On 05/02/2012 03:42 AM, Ralf Jung wrote:
> Hi,
>
> in addition to the constant flickering when running on AC, there is a more
> "high frequency" flickering immediately after plugging in the AC: For some 5
> to 10 seconds, the battery appears and disappears (according to upower) around
> once per second. There's also a short moment without battery after plugging
> out the AC.
> All this is gone after going to a kernel version without this patch applied.
>
> I did not notice unusual high CPU usage of upower on my system, however I
> noticed disc activity - according to iotop, upower is writing several MiB of
> data per minute to /var/lib/upower/ where it keeps some battery statistics. I
> do not know whether this is out of the ordinary.
>
> Kind regards,
> Ralf
>
>
> On Tuesday 01 May 2012 21:14:08 Jonathan Nieder wrote:
>> (cc-ing Andy)
>>
>> Adrian Fita wrote:
>>> Also, searching on Google after "upowerd device
>>> removed:/org/freedesktop/UPower/devices/battery_BAT0", reveals much
>>> more bug reports with the exact issue.
>>
>> Thanks. That confirms the high CPU consumption in upowerd ---
>> see [1], for example.
>>
>> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/987807
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox