lkml.org 
[lkml]   [2010]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] big continuous memory allocator v2
On Tue, 7 Sep 2010 17:25:59 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Tue, 07 Sep 2010 09:29:21 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
>
> > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> writes:
> >
> > > This is a page allcoator based on memory migration/hotplug code.
> > > passed some small tests, and maybe easier to read than previous
> > > one.
> >
> > Maybe I'm missing context here, but what is the use case for this?
> >
>
> I hear some drivers want to allocate xxMB of continuous area.(camera?)
> Maybe embeded guys can answer the question.

Ok what I wanted to say -- assuming you can make this work
nicely, and the delays (swap storms?) likely caused by this are not
too severe, it would be interesting for improving the 1GB pages on x86.

This would be a major use case and probably be enough
to keep the code around.

But it depends on how well it works.

e.g. when the zone is already fully filled how long
does the allocation of 1GB take?

How about when parallel programs are allocating/freeing
in it too?

What's the worst case delay under stress?

Does it cause swap storms?

One issue is also that it would be good to be able to decide
in advance if the OOM killer is likely triggered (and if yes
reject the allocation in the first place).

-Andi

--
ak@linux.intel.com -- Speaking for myself only.


\
 
 \ /
  Last update: 2010-09-07 10:49    [W:0.028 / U:22.160 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site