[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6599ad830803161855y1ceb8aa8t2f486434b521bd81@mail.gmail.com>
Date: Mon, 17 Mar 2008 09:55:59 +0800
From: "Paul Menage" <menage@...gle.com>
To: balbir@...ux.vnet.ibm.com
Cc: linux-mm@...ck.org, "Hugh Dickins" <hugh@...itas.com>,
"Sudhir Kumar" <skumar@...ux.vnet.ibm.com>,
"YAMAMOTO Takashi" <yamamoto@...inux.co.jp>, lizf@...fujitsu.com,
linux-kernel@...r.kernel.org, taka@...inux.co.jp,
"David Rientjes" <rientjes@...gle.com>,
"Pavel Emelianov" <xemul@...nvz.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"KAMEZAWA Hiroyuki" <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [RFC][0/3] Virtual address space control for cgroups
On Mon, Mar 17, 2008 at 9:50 AM, Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
>
> I am yet to measure the performance overhead of the accounting checks. I'll try
> and get started on that today. I did not consider making it a separate system,
> because I suspect that anybody wanting memory control would also want address
> space control (for the advantages listed in the documentation).
I'm a counter-example to your suspicion :-)
Trying to control virtual address space is a complete nightmare in the
presence of anything that uses large sparsely-populated mappings
(mmaps of large files, or large sparse heaps such as the JVM uses.)
If we want to control the effect of swapping, the right way to do it
is to control disk I/O, and ensure that the swapping is accounted to
that. Or simply just not give apps much swap space.
Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists