Messages in this thread | | | Date | Wed, 30 Jan 2002 13:43:09 -0600 (CST) | From | Oliver Xymoron <> | Subject | Re: [PATCH] per-cpu areas for 2.5.3-pre6 |
| |
On Wed, 30 Jan 2002, Oliver Xymoron wrote:
> On Wed, 30 Jan 2002, Rusty Russell wrote: > > > In message <Pine.LNX.4.44.0201291813110.25443-100000@waste.org> you write: > > > > > Nearly as good would be replacing the current logic for figuring out the > > > current processor id through current with logic to access the per-cpu > > > data. The primary use of that id is indexing that data anyway. > > > > And if you'd been reading this thread, you would have already seen > > this idea, and if you'd read the x86 code, you'd have realised that > > the tradeoff is arch-specific. > > Looking closer, I've found an issue with your patch related to the above, > so I think it bears closer examination.
Looking closer again (and not at 1am), I see I missed this line in reading your patch, sorry:
+#define this_cpu(var) per_cpu(var,smp_processor_id())
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".
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.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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/
| |