Messages in this thread | | | Date | Tue, 29 Mar 2016 11:44:54 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 0/3] nohz: Convert tick dependency mask to atomic_t |
| |
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Fri, Mar 25, 2016 at 09:48:47AM +0100, Ingo Molnar wrote: > > > > * Frederic Weisbecker <fweisbec@gmail.com> wrote: > > > > > As per Linus suggestion, lets convert the tick dependency mask to > > > atomic_t. Introduce atomic_fetch_or() and confine fetch_or() back to > > > scheduler guts. > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > > > timers/nohz > > > > > > HEAD: 7b7e5da5733f58668181077ec394a718e08c392c > > > > > > Thanks, > > > Frederic > > > --- > > > > > > Frederic Weisbecker (3): > > > atomic: Introduce atomic_fetch_or > > > nohz: Convert tick dependency mask to atomic_t > > > Revert "atomic: Export fetch_or()" > > > > > > > > > include/linux/atomic.h | 34 +++++++++++++-------------- > > > include/linux/sched.h | 4 ++-- > > > kernel/sched/core.c | 18 ++++++++++++++ > > > kernel/time/tick-sched.c | 61 ++++++++++++++++++++++++------------------------ > > > kernel/time/tick-sched.h | 2 +- > > > 5 files changed, 68 insertions(+), 51 deletions(-) > > > > Could you please also convert the sched/core.c usage, so that we can get rid of > > the private fetch_or() definition? Please also double check that it does not > > result in worse code generation. > > That involve converting thread_info::flags to atomic_t and given how much the type varies > across architectures:
Ah, yes - I did a similar analysis originally and then promptly forgot about it!
Harmonizing thread_info::flags does not look easy, given how much assembly code accesses this field.
So I suspect your original series of introducing the atomic_t interface while reverting back to the scheduler-specific auto-typing hack is fine after all.
> also given how much it is accessed (and that happens a lot in ASM as well). This > conversion deserves quite a whole project on its own. > > It might be possible to do it incrementally though.
So I don't even know where to begin with that:
- some 64-bit architectures want 32-bit flags - some 64-bit architectures want 64-bit flags - some 64-bit architectures may genuinely want more than 32 flags - some 64-bit architectures may want 64-bit word just because it's the fastest
... there's not a single natural data type on the C side that I can see this could be converted to :-/
Thanks,
Ingo
| |