[lkml]   [2008]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 00/41] cpu alloc / cpu ops v3: Optimize per cpu access
On Thu, 29 May 2008, Andrew Morton wrote:

> All seems reasonable to me. The obvious question is "how do we size
> the arena". We either waste memory or, much worse, run out.

The per cpu memory use by subsystems is typically quite small. We already
have an 8k limitation for percpu space for modules. And that does not seem
to be a problem.

> 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?

Typically these are fairly small 8 bytes * 5000 is only 20k.

> I wonder if we can arrange for the default to be overridden via a
> kernel boot option?

We could do that yes.

> Another obvious question is "how much of a problem will we have with
> internal fragmentation"? This might be a drop-dead showstopper.

But then per cpu data is not frequently allocated and freed.

Going away from allocpercpu saves a lot of memory. We could make this
128k or so to be safe?

 \ /
  Last update: 2008-05-30 07:25    [W:0.467 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site