Andi Kleen wrote:
quoted text
>> Here's an initial proposal for abstracting cpumask_t to be either
> 
> At least for some cases I don't think you'll get around defining
> a "nearby subset of CPUs that can be handled together" type. Handling 1K 
> objects all the time in one piece is simply not a good idea.
> 
> -Andi


Every time I stop to think about this, the problems with the cpu
operators come to mind.  Should there be a separate set?  Or simply
conversion functions to/from a "cpumask_subset" type?  

Thanks,
Mike
--
unsubscribe notice
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/