Message-Id: <bd1e8856-2dbe-4dcf-beb6-9c52437fb01a@app.fastmail.com>
Date: Wed, 03 Dec 2025 12:13:11 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Yuan Tan" <tanyuan@...ylab.org>,
 "Masahiro Yamada" <masahiroy@...nel.org>,
 "Nathan Chancellor" <nathan@...nel.org>,
 "Palmer Dabbelt" <palmer@...belt.com>, linux-kbuild@...r.kernel.org,
 linux-riscv@...ts.infradead.org
Cc: Linux-Arch <linux-arch@...r.kernel.org>, linux-kernel@...r.kernel.org,
 i@...kray.me, "Zhangjin Wu" <falcon@...ylab.org>, ronbogo@...look.com,
 z1652074432@...il.com, lx24@....ynu.edu.cn
Subject: Re: [PATCH v2 0/8] dce, riscv: Unused syscall trimming with PUSHSECTION and
 conditional KEEP()

On Wed, Dec 3, 2025, at 07:02, Yuan Tan wrote:
> On 11/7/2025 5:33 AM, Arnd Bergmann wrote:
>> On Tue, Nov 4, 2025, at 03:21, Yuan Tan wrote:
>>> For reference, here is the list of syscalls required to run Lighttpd.
>>>
>>> execve set_tid_address mount write brk mmap munmap getuid getgid getpid
>>> clock_gettime getcwd fcntl fstat read dup3 socket setsockopt bind listen
>>> rt_sigaction rt_sigprocmask newfstatat prlimit64 epoll_create1 epoll_ctl pipe2
>>> epoll_pwait accept4 getsockopt recvfrom shutdown writev getdents64 openat close
>>>

...

>>
>> Side note: I'm a  bit surprised to see fstat() in the list, since riscv
>> should only really support newfstat().
>
>
> The syscall list comes from a simple test environment rather than a
> workload I intend to optimize for deployment.
>
> The list I posted was generated using strace on RISC-V QEMU. I was
> looking at the ABI names, not the actual kernel syscall names.  One
> question here: for syscall trimming, should we discuss everything in
> terms of syscall ABI names or the actual kernel syscall function names?
> I would like to confirm your preference before I continue with the
> updated list.

Right, we clearly need to come up with a consistent naming here.
Unfortunately both the function names and the macro names can
be confusing here.

> For now, I'll continue the discussion in terms of syscall ABI names.

Ok

> Following your suggestion, I started by taking the syscall list required
> for the Lighttpd workload and expanded it into the corresponding
> functional groups.
>
> Here is a very preliminary draft of the syscall grouping, based on the
> systemd classification.
>
> https://pastebin.com/raw/Yx92bb3m
>
> Then, I wrote a small script that classifies each syscall from lighttpd
> into its category and then enumerates all syscalls belonging to those
> categories.
>
> It addresses two of the items you asked for
>
> - Identifying the syscall families related to my minimal Lighttpd
>   workload
>
> - Enumerating which syscalls appear in those categories and could
>   potentially become optional
>
> ```
> Categories present in lighttpd_syscalls.txt:
>   @basic-io: 5 / 16
>   @clock: 1 / 8
>   @default: 9 / 30
>   @file-system: 6 / 47
>   @io-event: 3 / 7
>   @ipc: 1 / 23
>   @mount: 1 / 13
>   @network-io: 8 / 18
>   @signal: 2 / 14
> Total unique categories: 9
> Total categories defined: 30

Thanks for compiling the list, this is very useful!

It's clear that the systemd categories have a someone different
purpose, which does mean that some of the categories pull in
way more syscalls than we need for your testcase:

- ipc is mostly for sysvipc (controlled by CONFIG_SYSVIPC, but not used
  in your workload), but it also includes pipe2, which you do use.

- network-io includes all the socket interfaces, and I think
  that makes sense as a category (CONFIG_NET).

- clock contains all the posix clock and timer support, but you
  only use clock_gettime(). We have CONFIG_POSIX_TIMERS, which
  you can disable to get close to what you want here.

- The 'mount' category has gained a lot of non-optional syscalls
  over the past few years, but you only use the traditonal
  'mount'. Since the general idea is to move away from the mount
  syscall to the newer ones, I'm not sure it makes sense to
  have additional options here, but that depends a bit on the
  amount of space savings and may be worth trying.

> This produces a list of 176 syscalls across 9 categories that are
> relevant to the workload. The output also shows which categories do not
> appear in this workload (21 categories with 0 syscalls used).
>
> If the categorization works this way, it's actually quite surprising
> that even such a simple workload would pull in as many as 176 syscalls.
> I'm not sure yet what the actual trimming impact will look like after
> building, but I will test that next.

Sounds good. See if you can disable CONFIG_SYSVIPC and
CONFIG_POSIX_TIMERS in those tests, in addition to the ones from
categories you list as being unused.

      Arnd

Powered by blists - more mailing lists