On Tue, 7 Sep 2010 17:25:59 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > On Tue, 07 Sep 2010 09:29:21 +0200 > Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>