on x86 I don't care; we don't actually change these dynamically much[1].
But if you have 1 or 2 things in mind to use,
I would suggest copying those 2 integers instead as we go, rather than
the index.
Saves refcounting/locking etc etc nightmare as well on the other
subsystems' datastructures..
... which you likely need to do to actually follow that index.
Hmm, yeah. That's a fair argument. That is true, the races and locks/refcnt are
something we have to worried about. But also we may want to prevent duplicating
the data
across the subsystems.
there is still one master set of data (cpuidle), just when cpuidle picks a
hardware state
that (at that time) has a specific latency/break even, it stores a copy of the
data in the rq.
That's not really duplication in the bad sense, there's still only one master
copy of the data.
Just you take a snapshot of a value/pair of values at a point in time and
effectively
cache it in the rq for lockless access (and to cope with the master changing
later
that doesn't reflect the reality of this rq)
I'd say that's a fair tradeoff, esp given the locking/refcount angle
(the fewer outside locks the scheduler level code wants the better off we all
are by a lot)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
