Eric W. Biederman wrote:

quoted text
> First off right now reserving more than about 64KB is ridiculous.  We rightly
> don't have that many per cpu variables.

We do. The case has been made numerous times that we need at least several megabytes of per cpu memory in case someone creates gazillions of ip tunnels etc etc.


quoted text
>> instead of looking it up in a table because that will save a memory access on
>> per_cpu().
> 
> ???? Optimizing per_cpu seems to be the wrong path.  If you want to go fast you
> access the data on the cpu you start out on.

Yes most arches provide specialized registers for local per cpu variable access. There are cases though in which you have to access another processors cpu space.

quoted text
>> Maybe there is another way of arranging things that would allow for this?
> 
> Yes.  Start with a patch that doesn't have freaky failures that can't be understood
> or bisected because the patch is too big.  The only reason we are having a conversation

The patches are reasonably small. The problem that Mike seems to have is early boot debugging.
--
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/