Messages in this thread | | | Date | Fri, 19 Mar 2004 16:59:28 -0800 | From | Paul Jackson <> | Subject | Re: [PATCH] Introduce nodemask_t ADT [0/7] |
| |
> > When I looked at the assembly code generated on my one lung i386 box for > > native gcc 3.3.2, it looked pretty good (to my untrained eye) using a > > struct of an array of unsigned longs, both for the single unsigned long > > (<= 32 bits) and multiple unsigned long cases. > > The code you wrote, or my patch?
The code I wrote and appended yesterday. Though, as I realize now in my post of a few minutes ago, there are perhaps 8 places where instead of calling various bitmap_ops() unconditionally ('and', 'or', ...) it would be better to peel off the one-word case and inline it.
> Sounds like a good idea. We certainly shouldn't be passing huge masks > on the stack, but for small masks like, i dunno, <= 4 ULs (the same > optimization Bill's code makes) it's no problem.
Don't we have quite a few places with one, two, even three local variables of type cpumask_t? Which live on the stack? For all mask implementations? Grep around for "cpumask_t.*,.*," and many of the lines you see appear to be declarations of such local cpumask_t variables.
And we need to be careful of converting pass by value semantics for small cpumasks into pass by reference semantics for large cpumasks, as a hidden feature of the implementation. One could code some cute bugs that way.
Better, I think, to provide a reasonably rich set of mask ops, so that the using code need not have anymore than the essential number of distinctly different masks hanging around at once in order to write clear code.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.650.933.1373 - 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/
| |