lkml.org 
[lkml]   [2008]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 00/41] cpu alloc / cpu ops v3: Optimize per cpu access
Andrew Morton wrote:
> On Thu, 29 May 2008 20:56:20 -0700 Christoph Lameter <clameter@sgi.com> wrote:
>
>> In various places the kernel maintains arrays of pointers indexed by
>> processor numbers. These are used to locate objects that need to be used
>> when executing on a specirfic processor. Both the slab allocator
>> and the page allocator use these arrays and there the arrays are used in
>> performance critical code. The allocpercpu functionality is a simple
>> allocator to provide these arrays.
>
> All seems reasonable to me. The obvious question is "how do we size
> the arena". We either waste memory or, much worse, run out.
>
> And running out is a real possibility, I think. Most people will only
> mount a handful of XFS filesystems. But some customer will come along
> who wants to mount 5,000, and distributors will need to cater for that,
> but how can they?
>
> I wonder if we can arrange for the default to be overridden via a
> kernel boot option?
>
>
> Another obvious question is "how much of a problem will we have with
> internal fragmentation"? This might be a drop-dead showstopper.

One problem with variable sized cpu_alloc area is this comment in bitmap.h:

* Note that nbits should be always a compile time evaluable constant.
* Otherwise many inlines will generate horrible code.

I'm guessing since this will be of low use and not performance critical,
then we can ignore the "horrible code"? ;-)

Thanks,
Mike



\
 
 \ /
  Last update: 2008-06-04 17:11    [W:0.274 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site