linux-kernel - Re: [PATCH] procfs: add syscall statistics

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: <YpDBjDTpS4evca3F@hirez.programming.kicks-ass.net>
Date:   Fri, 27 May 2022 14:18:20 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Zhang Yuchen <zhangyuchen.lcr@...edance.com>
Cc:     akpm@...ux-foundation.org, david@...hat.com, mingo@...hat.com,
        ast@...nel.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-s390@...r.kernel.org,
        linux-api@...r.kernel.org, fam.zheng@...edance.com
Subject: Re: [PATCH] procfs: add syscall statistics

On Fri, May 27, 2022 at 07:09:59PM +0800, Zhang Yuchen wrote:
> Add /proc/syscalls to display percpu syscall count.
> 
> We need a less resource-intensive way to count syscall per cpu
> for system problem location.
> 
> There is a similar utility syscount in the BCC project, but syscount
> has a high performance cost.
> 
> The following is a comparison on the same machine, using UnixBench
> System Call Overhead:
> 
>     ┏━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━┳━━━━━━━━┓
>     ┃ Change        ┃ Unixbench Score ┃ Loss   ┃
>     ┡━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━╇━━━━━━━━┩
>     │ no change     │ 1072.6          │ ---    │
>     │ syscall count │ 982.5           │ 8.40%  │
>     │ bpf syscount  │ 614.2           │ 42.74% │
>     └───────────────┴─────────────────┴────────┘
> 
> UnixBench System Call Use sys_gettid to test, this system call only reads
> one variable, so the performance penalty seems large. When tested with
> fork, the test scores were almost the same.
> 
> So the conclusion is that it does not have a significant impact on system
> call performance.
> 
> This function depends on CONFIG_FTRACE_SYSCALLS because the system call
> number is stored in syscall_metadata.

Death by a thousand cuts. 99% of people won't ever use this.

NAK