[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151214171143.GD23614@danjae.kornet>
Date: Tue, 15 Dec 2015 02:11:43 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...nel.org>, David Ahern <dsahern@...il.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Andi Kleen <andi@...stfloor.org>,
Stephane Eranian <eranian@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)
On Mon, Dec 14, 2015 at 05:56:14PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 15, 2015 at 01:38:30AM +0900, Namhyung Kim wrote:
> > It requires many changes, but basically I also like the split-up since
> > it's easier to deal with. IIRC there was an opinion (Andi?) regarding
> > single-file vs multi-file. The file access will be better for single
> > file so I changed my earlier implementation to use indexed single data
> > file instead of multiple files.
>
> The page-cache has a lock per inode, so by having all CPUs populate the
> one file you get contention on that.
>
> Also, I suppose you'll have to arbitrate ranges in that file for each
> cpu to make it work, that too could get you some contention.
>
> Having a file per cpu avoids all that.
Right. Now I recall that it was about *report* (not record) time
accessing single file vs. multi files.
At record time we should use file per cpu. I combined them into
one with index at post-processing time in my earlier work.
Thanks for clarification!
Namhyung
--
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