linux-kernel - Re: [PATCHv2 00/25] perf tool: Add support for multiple data file storage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Sep 2013 11:15:10 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Adrian Hunter <adrian.hunter@...el.com>
Cc:	Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Namhyung Kim <namhyung@...nel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Andi Kleen <ak@...ux.intel.com>,
	David Ahern <dsahern@...il.com>
Subject: Re: [PATCHv2 00/25] perf tool: Add support for multiple data file
 storage

On Tue, Sep 10, 2013 at 09:54:38AM +0300, Adrian Hunter wrote:
> On 09/09/13 14:17, Peter Zijlstra wrote:

> > The only reason I wanted this is so that each thread can write its own
> > data. The current one file thing is an immense bottle-neck for big
> > machines.
> 
> Do you need multiple files for that?  Why not just feed writes to a pool of
> threads?

Not sure I understand what you mean there. Since we have a (or multiple)
event per cpu it doesn't make sense to read that data from another cpu
and have that write it to disk. That completely destroys the locality.

Instead the suggestion was to have a thread per cpu (bound) to empty out
the per cpu mmap buffer(s) and write them to disk.

Now the only way to coherently do that into a single file is to do some
streams implementation, which I suppose is possible. Pre-allocate
large-ish sections per thread and mark them as such, then let the thread
spool data into it, when full allocate a new section.

However this would result in allocation-block-size*nr_cpus minimal file
sizes, which wouldn't be a problem per-se since they can be sparse.

It will however pretty much mess up Jolsa's max-MBs per file thing and
it is of course slightly more complex than having a file per cpu/thread.
And is more likely to create kernel lock contention; the pagecache locks
are typically per inode, bouncing those around the machine isn't nice
either.
--
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/