lkml.org 
[lkml]   [2010]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 10/14] Add /sys trigger for per-node memory compaction
On Tue, 6 Apr 2010 17:56:01 -0400
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 7 Apr 2010 09:31:48 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > A cgroup which controls placement of memory is cpuset.
>
> err, yes, that.
>
> > One idea is per cpuset. But per-node seems ok.
>
> Which is superior?
>
> Which maps best onto the way systems are used (and onto ways in which
> we _intend_ that systems be used)?
>

node has hugepage interface now.

[root@bluextal qemu-kvm-0.12.3]# ls /sys/devices/system/node/node0/hugepages/
hugepages-2048kB

So, per-node knob is straightforward.

> Is the physical node really the best unit-of-administration? And is
> direct access to physical nodes the best means by which admins will
> manage things?

In these days, we tend to use "setup tool" for using cpuset, etc.
(as libcgroup.)

Considering control by userland-support-soft, I think pernode is not bad.
And per-cpuset requires users to mount cpuset.
(Now, most of my customer doesn't use cpuset.)


Thanks,
-Kame




\
 
 \ /
  Last update: 2010-04-07 03:25    [W:0.133 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site