Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH] per-cpu areas for 2.5.3-pre6 | Date | Thu, 31 Jan 2002 10:00:51 +1100 |
| |
In message <Pine.LNX.4.44.0201301259520.11802-100000@waste.org> you write: > I still think that tracking per_cpu_offset in task struct to eventually > replace current->processor is a win. Basically everyone except Sparc goes > through current anyway for smp_processor_id and Sparc caches current in a > register. Please elucidate your reference to "arch-specific tradeoffs".
Placing useful information in the task struct is a hack. A useful hack on the register-starved x86, of course. PPC64 will probably use a register, too.
BTW, apologies for my previous accusations of not reading the thread. Your reply predated mine by 12 hours: http://www.ozlabs.org/~rusty/Stupidity.html#9
> Also, it'd be nice to unmap the original copy of the area or at least > poison it to catch silent references to var without going through > this_cpu, which will probably prove very hard to find. If there were a way > to do this at the C source level and catch such things at compile time, > that'd be even better, but I can't see a way to do it without grotty > macros.
My first cut did this, with a macro:
DECLARE_PER_CPU(int x);
This allows you to munge x into x__per_cpu, to catch "bare" references. But I decided against it for two reasons: firstly __per_cpu_data is nicer, and secondly my proc/sys rewrite can handle per-cpu data easily if the name is valid.
In practice, grep should be sufficient.
Cheers! Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |