linux-kernel - Re: [PATCH RFC] hist lookups

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:   Sun, 11 Nov 2018 20:41:32 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     David Miller <davem@...emloft.net>
Cc:     acme@...nel.org, linux-kernel@...r.kernel.org, namhyung@...nel.org,
        jolsa@...nel.org
Subject: Re: [PATCH RFC] hist lookups

On Thu, Nov 08, 2018 at 05:07:21PM -0800, David Miller wrote:
> From: Jiri Olsa <jolsa@...hat.com>
> Date: Thu, 8 Nov 2018 08:13:03 +0100
> 
> > we could separated fork/mmaps to separate dummy event map, or just
> > parse them out in the read thread and create special queue for them
> > and drop just samples in case we are behind
> 
> What you say at the end here is basically what I am proposing.
> 
> Perf dequeues events from mmap ring as fast as possible.
> 
> Perf has two internal queues, high priority and low priority.
> 
> High priority events are never dropped.
> 
> Low priority events are dropped on overload, oldest first.

I added the dropping logic, it's simple so far..

the processing thread will drop (not process) samples
which gets behind the latest event time more then
the 'refresh rate' seconds

adding separate queues for samples and other events is
possible, but it looks like the above simple solution
could be ok for now

thanks,
jirka