From: Andrew Morton <akpm@linux-foundation.org>
To: Greg Thelen <gthelen@google.com>
Cc: glommer@parallels.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: kmem accounting netperf data
Date: Tue, 20 Nov 2012 23:52:24 -0800 [thread overview]
Message-ID: <20121120235224.f4e9e1c6.akpm@linux-foundation.org> (raw)
In-Reply-To: <xr937gplwkcn.fsf@gthelen.mtv.corp.google.com>
On Fri, 16 Nov 2012 09:03:52 -0800 Greg Thelen <gthelen@google.com> wrote:
> 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.
Let's cc the netdev guys, who will be pleased to hear that we didn't
break their stuff for once ;)
Thanks for testing - it was a concern.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Greg Thelen <gthelen@google.com>
Cc: glommer@parallels.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: kmem accounting netperf data
Date: Tue, 20 Nov 2012 23:52:24 -0800 [thread overview]
Message-ID: <20121120235224.f4e9e1c6.akpm@linux-foundation.org> (raw)
In-Reply-To: <xr937gplwkcn.fsf@gthelen.mtv.corp.google.com>
On Fri, 16 Nov 2012 09:03:52 -0800 Greg Thelen <gthelen@google.com> wrote:
> 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.
Let's cc the netdev guys, who will be pleased to hear that we didn't
break their stuff for once ;)
Thanks for testing - it was a concern.
next prev parent reply other threads:[~2012-11-21 7:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-16 17:03 kmem accounting netperf data Greg Thelen
2012-11-16 17:03 ` Greg Thelen
2012-11-21 7:52 ` Andrew Morton [this message]
2012-11-21 7:52 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121120235224.f4e9e1c6.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=glommer@parallels.com \
--cc=gthelen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.