linux-kernel - Re: [PATCHSET 00/16] perf top: Add multi-thread support (v1)

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:	Thu, 10 Dec 2015 17:49:35 +0900
From:	Namhyung Kim <namhyung@...il.com>
To:	Ingo Molnar <mingo@...nel.org>, Namhyung Kim <namhyung@...nel.org>
CC:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jiri Olsa <jolsa@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	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 December 10, 2015 5:01:18 PM GMT+09:00, Ingo Molnar <mingo@...nel.org> wrote:
>
>* Namhyung Kim <namhyung@...nel.org> wrote:
>
>> Hello,
>> 
>> This patchset if an attempt to support multi-threading in perf top.
>> In fact, perf top already run on two threads - a worker thread and a
>> display thread.  However processing all samples with a single thread
>> in a large machine can have scalability problems.
>> 
>> This patchset extends it to have multiple worker threads to process
>> samples concurrently.  Users can control the number of threads using
>>  --num-thread option.  And there's a collector thread for passing
>hist
>> entries from worker threads to the display thread.
>
>Could you please make the number of threads default to the number of
>CPUs?
>
>Since perf top is doing one perf event per CPU anyway, that's a pretty
>natural 
>model.
>
>( I think 'perf record' should use per CPU threads as well to receive
>events, to 
>address the 'IO overload' problems with -g recording on larger CPU
>counts. )

IIRC David said that thread per cpu seems too much
especially on a large system (like ~1024 cpu).  I have no idea 
what's the reasonable default on the system, so I chose 1/4 
of map buffers (i.e. cpus for most cases). But I think I should
take non-system-wide mode into account too.

Thanks
Namhyung

Hi Ingo,
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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/