linux-kernel - RE: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

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:	Fri, 12 Jun 2015 22:41:36 +0000
From:	"Liang, Kan" <kan.liang@...el.com>
To:	David Ahern <dsahern@...il.com>, Andi Kleen <andi@...stfloor.org>
CC:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Huang, Ying" <ying.huang@...el.com>
Subject: RE: [PATCH 1/1] perf,tools: add time out to force stop endless mmap
 processing

> 
> On 6/12/15 2:39 PM, Liang, Kan wrote:
> > Here are the test results.
> > Please note that I get "synthesized threads took..." after the test case
> exit.
> > It means both way have the same issue.
> 
> Got it. So what you really mean is launching perf on an already running
> process perf never finishes initializing. There are several types of problems
> like this. For example on a sparc system with a 1024 cpus if I launch perf
> (top or record) after starting a kernel build with make -j
> 1024 the build finishes before perf starts collecting samples. ie., it never
> finishes walking /proc until the build is complete. task_diag does not solve
> that problem either and in general the procps tools can't handle it either
> (ps or top for example).
> 

We should not stop using system wide perf top/record just because there
are some threads which have huge/growing maps.
The maps information is not critical for sampling.

If task_diag does not solve this problem, I think we still need a time out
to force stop endless mmap processing. It's the simplest working
solution so far.


> For your test case what happens if you run:
>    perf record -- test-app
> 
> Is perf overloaded with mmap samples? does it keep up or do you have to
> jack the mmap size (-m arg)?

No.
synthesize_threads will not be called unless you specify the process/threads/cpu.
(Please refer to __machine__synthesize_threads.)
So it works well.

perf record -- ./run case-small-allocs
[ perf record: Woken up 3844 times to write data ]
[ perf record: Captured and wrote 1001.897 MB perf.data (26259688 samples) ]


Thanks,
Kan

--
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/