[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20121101170454.b7713bce.akpm@linux-foundation.org>
Date: Thu, 1 Nov 2012 17:04:54 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Glauber Costa <glommer@...allels.com>
Cc: <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
<kamezawa.hiroyu@...fujitsu.com>,
Johannes Weiner <hannes@...xchg.org>,
Tejun Heo <tj@...nel.org>, Michal Hocko <mhocko@...e.cz>,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH v6 00/29] kmem controller for memcg.
On Thu, 1 Nov 2012 16:07:16 +0400
Glauber Costa <glommer@...allels.com> wrote:
> Hi,
>
> This work introduces the kernel memory controller for memcg. Unlike previous
> submissions, this includes the whole controller, comprised of slab and stack
> memory.
I'm in the middle of (re)reading all this. Meanwhile I'll push it all
out to http://ozlabs.org/~akpm/mmots/ for the crazier testers.
One thing:
> Numbers can be found at https://lkml.org/lkml/2012/9/13/239
You claim in the above that the fork worload is 'slab intensive". Or
at least, you seem to - it's a bit fuzzy.
But how slab intensive is it, really?
What is extremely slab intensive is networking. The networking guys
are very sensitive to slab performance. If this hasn't already been
done, could you please determine what impact this has upon networking?
I expect Eric Dumazet, Dave Miller and Tom Herbert could suggest
testing approaches.
--
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