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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181107033234.djng6kas4tjkevln@linux-r8p5>
Date:   Tue, 6 Nov 2018 19:32:34 -0800
From:   Davidlohr Bueso <dave@...olabs.net>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Daniel Colascione <dancol@...gle.com>, longman@...hat.com,
        linux-fsdevel@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Davidlohr Bueso <dbueso@...e.de>
Subject: Re: [PATCH] fs/proc: introduce /proc/stat2 file

On Tue, 06 Nov 2018, Andrew Morton wrote:

>It would be interesting to know precisely which stat fields the
>database-which-shall-not-be-named is looking for.  Then we could cook
>up a very whizzy way of getting at the info.

The ctxt field, afaik. In any case they have been able to work around
the bottleneck. I'm not sure if that is the case for Waiman, however.

>
>A downside of the stat2 approach is that applications will need to be
>rebuilt.  And hopefully when people do this, they'll open
>"/etc/my-app-name/symlink-to-proc-stat" (or use per-application config)
>so they won't need a rebuild when we add /proc/stat3!
>
>A /proc/change-how-stat-works tunable would avoid the need to rebuild
>applications.  But if a system still has some applications which want
>the irq info then that doesn't work.
>
>It's all very sad, really.
>
>btw,
>
>> +The stat2 file acts as a performance alternative to /proc/stat for workloads
>> +and systems that care and are under heavy irq load. In order to to be completely
>> +compatible, /proc/stat and /proc/stat2 are identical with the exception that the
>> +later will show 0 for any (hard)irq-related fields. This refers particularly
>
>"latter"
>
>> +to the "intr" line and 'irq' column for that aggregate in the cpu line.
>
>btw2, please quantify "poor performance".  That helps us determine how
>much we care about all of this!

Up to a quarter of a second is what was reported as being spent every time
/proc/stat is used. This is with 1k cores and 4k interrupts.

Thanks,
Davidlohr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ