Prev: [patch 0/2] pci: raw_spinlock annotations
Next: percpu: add __percpu sparse annotations to trace
From: KAMEZAWA Hiroyuki on 23 Mar 2010 20:30
On Tue, 23 Mar 2010 12:25:44 +0000
Mel Gorman <mel(a)csn.ul.ie> wrote:

> This patch adds a per-node sysfs file called compact. When the file is
> written to, each zone in that node is compacted. The intention that this
> would be used by something like a job scheduler in a batch system before
> a job starts so that the job can allocate the maximum number of
> hugepages without significant start-up cost.
>
> Signed-off-by: Mel Gorman <mel(a)csn.ul.ie>
> Acked-by: Rik van Riel <riel(a)redhat.com>
> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com>



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 6 Apr 2010 20:10
On Fri, 2 Apr 2010 17:02:44 +0100
Mel Gorman <mel(a)csn.ul.ie> wrote:

> This patch adds a per-node sysfs file called compact. When the file is
> written to, each zone in that node is compacted. The intention that this
> would be used by something like a job scheduler in a batch system before
> a job starts so that the job can allocate the maximum number of
> hugepages without significant start-up cost.

Would it make more sense if this was a per-memcg thing rather than a
per-node thing?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: KAMEZAWA Hiroyuki on 6 Apr 2010 20:40
On Tue, 6 Apr 2010 17:05:59 -0700
Andrew Morton <akpm(a)linux-foundation.org> wrote:

> On Fri, 2 Apr 2010 17:02:44 +0100
> Mel Gorman <mel(a)csn.ul.ie> wrote:
>
> > This patch adds a per-node sysfs file called compact. When the file is
> > written to, each zone in that node is compacted. The intention that this
> > would be used by something like a job scheduler in a batch system before
> > a job starts so that the job can allocate the maximum number of
> > hugepages without significant start-up cost.
>
> Would it make more sense if this was a per-memcg thing rather than a
> per-node thing?

memcg doesn't have any relationship with placement of memory (now).
It's just controls the amount of memory.
So, memcg has no relationship with compaction.

A cgroup which controls placement of memory is cpuset.
One idea is per cpuset. But per-node seems ok.

Thanks,
-Kame

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 6 Apr 2010 21:00
On Wed, 7 Apr 2010 09:31:48 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)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)?

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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: KAMEZAWA Hiroyuki on 6 Apr 2010 21:30
On Tue, 6 Apr 2010 17:56:01 -0400
Andrew Morton <akpm(a)linux-foundation.org> wrote:

> On Wed, 7 Apr 2010 09:31:48 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)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(a)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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [patch 0/2] pci: raw_spinlock annotations
Next: percpu: add __percpu sparse annotations to trace