From: Greg Thelen <gthelen@google.com>
To: glommer@parallels.com
Subject: kmem accounting netperf data
cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Date: Fri, 16 Nov 2012 09:03:52 -0800
Message-ID: <xr937gplwkcn.fsf@gthelen.mtv.corp.google.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1368
Lines: 34

We ran some netperf comparisons measuring the overhead of enabling
CONFIG_MEMCG_KMEM with a kmem limit.  Short answer: no regression seen.

This is a multiple machine (client,server) netperf test.  Both client
and server machines were running the same kernel with the same
configuration.

A baseline run (with CONFIG_MEMCG_KMEM unset) was compared with a full
featured run (CONFIG_MEMCG_KMEM=y and a kmem limit large enough not to
put additional pressure on the workload).  We saw no noticeable
regression running:
- TCP_CRR efficiency, latency
- TCP_RR latency, rate
- TCP_STREAM efficiency, throughput
- UDP_RR efficiency, latency
The tests were run with a varying number of concurrent connections
(between 1 and 200).

The source came from one of Glauber's branches
(git://git.kernel.org/pub/scm/linux/kernel/git/glommer/memcg
kmemcg-slab):
  commit 70506dcf756aaafd92f4a34752d6b8d8ff4ed360
  Author: Glauber Costa <glommer@parallels.com>
  Date:   Thu Aug 16 17:16:21 2012 +0400

      Add slab-specific documentation about the kmem controller

It's not the latest source, but I figured the data might still be
useful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/