From: Johannes Weiner <hannes@cmpxchg.org>
To: Balbir Singh <bsingharora@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Michal Hocko <mhocko@suse.cz>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [patch 0/8] mm: memcg fixlets for 3.3
Date: Thu, 24 Nov 2011 10:45:32 +0100 [thread overview]
Message-ID: <20111124094532.GF6843@cmpxchg.org> (raw)
In-Reply-To: <CAKTCnzk0Jzq+o1Qv9hOO5ssO7U_xe1ZqUaWDhWEeJAQQPjPudg@mail.gmail.com>
On Thu, Nov 24, 2011 at 11:39:39AM +0530, Balbir Singh wrote:
> On Wed, Nov 23, 2011 at 9:12 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> >
> > Here are some minor memcg-related cleanups and optimizations, nothing
> > too exciting. The bulk of the diffstat comes from renaming the
> > remaining variables to describe a (struct mem_cgroup *) to "memcg".
> > The rest cuts down on the (un)charge fastpaths, as people start to get
> > annoyed by those functions showing up in the profiles of their their
> > non-memcg workloads. More is to come, but I wanted to get the more
> > obvious bits out of the way.
>
> Hi, Johannes
>
> The renaming was a separate patch sent from Raghavendra as well, not
> sure if you've seen it.
I did and they are already in -mm, but unless I miss something, those
were only for memcontrol.[ch]. My patch is for the rest of mm.
> What tests are you using to test these patches?
I usually run concurrent kernbench jobs in separate memcgs as a smoke
test with these tools:
http://git.cmpxchg.org/?p=statutils.git;a=summary
"runtest" takes a job-spec file that looks a bit like RPM spec to
define works with preparation and cleanup phases, and data collectors.
The memcg kernbench job I use is in the examples directory. You just
need to put separate kernel source directories into place (linux-`seq
-w 04`) and then launch it like this:
runtest -s memcg-kernbench.load `uname -r`
which will run the test and collect memory.stat of the parent memcg
every second, which you can then further evaluate with the other
tools:
readdict < `uname -r`-memory.stat.data | columns 14 15 | plot
for example, where readdict translates the "key value" lines of
memory.stat into tables where each value is on its own row. Columns
14 and 15 are total_cache and total_rss (find out with cat -n -- yeah,
still a bit rough). You need python-matplotlib for plot to work.
Multiple runs can be collected into the same logfiles and then fold
ever-increasing counters with the "events" tool. For example, to find
the average fault count, you would do something like this (19 =
total_pgfault, 20 = total_pgmajfault):
for x in `seq 10`; do runtest -s foo.load foo`; done
readdict < foo-memory.stat.data | columns 19 20 | events | mean -s
Oh, and workload runtime is always recorded in NAME.time, so
events < `uname -r`.time
gives you the timings of each run, which you can then further process
with "mean" or "median" again.
prev parent reply other threads:[~2011-11-24 9:45 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-23 15:42 [patch 0/8] mm: memcg fixlets for 3.3 Johannes Weiner
2011-11-23 15:42 ` [patch 1/8] mm: oom_kill: remove memcg argument from oom_kill_task() Johannes Weiner
2011-11-23 22:35 ` David Rientjes
2011-11-23 23:57 ` KAMEZAWA Hiroyuki
2011-11-24 9:07 ` Michal Hocko
2011-11-28 0:37 ` Balbir Singh
2011-11-23 15:42 ` [patch 2/8] mm: unify remaining mem_cont, mem, etc. variable names to memcg Johannes Weiner
2011-11-23 22:40 ` David Rientjes
2011-11-23 23:58 ` KAMEZAWA Hiroyuki
2011-11-24 9:17 ` Michal Hocko
2011-11-28 0:42 ` Balbir Singh
2011-11-23 15:42 ` [patch 3/8] mm: memcg: clean up fault accounting Johannes Weiner
2011-11-24 0:00 ` KAMEZAWA Hiroyuki
2011-11-24 9:33 ` Michal Hocko
2011-11-24 9:51 ` Johannes Weiner
2011-11-28 0:45 ` Balbir Singh
2011-11-23 15:42 ` [patch 4/8] mm: memcg: lookup_page_cgroup (almost) never returns NULL Johannes Weiner
2011-11-24 0:01 ` KAMEZAWA Hiroyuki
2011-11-24 9:52 ` Michal Hocko
2011-11-24 10:05 ` Johannes Weiner
2011-11-24 10:26 ` Michal Hocko
2011-11-28 9:15 ` Johannes Weiner
2011-11-28 9:34 ` Johannes Weiner
2011-11-28 10:12 ` Michal Hocko
2011-11-28 7:03 ` Balbir Singh
2011-11-28 9:17 ` Johannes Weiner
2011-11-23 15:42 ` [patch 5/8] mm: memcg: remove unneeded checks from newpage_charge() Johannes Weiner
2011-11-24 0:04 ` KAMEZAWA Hiroyuki
2011-11-24 9:04 ` Johannes Weiner
2011-11-24 10:30 ` Michal Hocko
2011-11-24 11:58 ` Johannes Weiner
2011-11-23 15:42 ` [patch 6/8] mm: memcg: remove unneeded checks from uncharge_page() Johannes Weiner
2011-11-24 0:06 ` KAMEZAWA Hiroyuki
2011-11-24 9:06 ` Johannes Weiner
2011-11-24 10:34 ` Michal Hocko
2011-11-23 15:42 ` [patch 7/8] mm: memcg: modify PageCgroupAcctLRU non-atomically Johannes Weiner
2011-11-23 18:52 ` Hugh Dickins
2011-11-24 8:53 ` Johannes Weiner
2011-11-24 0:09 ` KAMEZAWA Hiroyuki
2011-11-24 8:55 ` Johannes Weiner
2011-11-23 15:42 ` [patch 8/8] mm: memcg: modify PageCgroupCache non-atomically Johannes Weiner
2011-11-24 0:13 ` KAMEZAWA Hiroyuki
2011-11-24 9:13 ` Johannes Weiner
2011-11-24 6:09 ` [patch 0/8] mm: memcg fixlets for 3.3 Balbir Singh
2011-11-24 9:45 ` Johannes Weiner [this message]
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=20111124094532.GF6843@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=bsingharora@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).