linux-kernel - Re: [PATCHES/RFC] Re: A concern about overflow ring buffer mode

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]

Message-Id: <20181029.141656.565374870463385142.davem@davemloft.net>
Date:   Mon, 29 Oct 2018 14:16:56 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     kan.liang@...ux.intel.com
Cc:     acme@...nel.org, linux-kernel@...r.kernel.org, wangnan0@...wei.com,
        jolsa@...nel.org, namhyung@...nel.org, kan.liang@...el.com,
        ak@...ux.intel.com, yao.jin@...ux.intel.com, peterz@...radead.org
Subject: Re: [PATCHES/RFC] Re: A concern about overflow ring buffer mode

From: "Liang, Kan" <kan.liang@...ux.intel.com>
Date: Mon, 29 Oct 2018 14:20:15 -0400

> You didn't see any warning before the patch. I think it is just
> because perf top hides the problem.

Quite honestly, the last time I played around with this:

1) The new ring buffer mode didn't exist

2) perf started up much more quickly and was much more responsive
   than it is these days

It used to handle a 128-cpu system doing a parallel kernel build
with no problems, no dropped events, nothing.

Something has changed to make perf more bloated and slow, and one by
one I'm trying to identify and deal with these issues rather than
just make perf abort when it can't keep up which is the approach
that has seem to have taken over.  That's to me is just wrong.

One point I want to make clear, dropping things like mmap events will
make perf run more slowly not more fast.

I keep trying to explain this over and over.

If you drop map events, you have no range into which to fit samples.

Therefore samples create a unique histogram entries, and the histogram
table grows to be quite huge.  And this slows down perf significantly
because every new sample and histogram decay walks this table, sorting
it, killing off old entries, finding a place for new ones, etc.

I really think dropping events causes more harm than good in this
case, therefore.

This also happens when perf cannot find a symbol, for example in a
binary or library with no symbols.  I see this as an area for
significant improvement.