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
| ||
|
Date: Fri, 22 Apr 2022 14:25:12 +0200 From: Miklos Szeredi <miklos@...redi.hu> To: Bernd Schubert <bschubert@....com> Cc: Linux-FSDevel <linux-fsdevel@...r.kernel.org>, Linux Kernel <linux-kernel@...r.kernel.org>, Dharmendra Singh <dsingh@....com>, Boaz Harrosh <boaz@...xistor.com>, Sagi Manole <sagim@...app.com> Subject: Re: RFC fuse waitq latency On Mon, 28 Mar 2022 at 15:21, Bernd Schubert <bschubert@....com> wrote: > > I would like to discuss the user thread wake up latency in > fuse_dev_do_read(). Profiling fuse shows there is room for improvement > regarding memory copies and splice. The basic profiling with flame graphs > didn't reveal, though, why fuse is so much > slower (with an overlay file system) than just accessing the underlying > file system directly and also didn't reveal why a single threaded fuse > uses less than 100% cpu, with the application on top of use also using > less than 100% cpu (simple bonnie++ runs with 1B files). > So I started to suspect the wait queues and indeed, keeping the thread > that reads the fuse device for work running for some time gives quite > some improvements. Might be related: I experimented with wake_up_sync() that didn't meet my expectations. See this thread: https://lore.kernel.org/all/1638780405-38026-1-git-send-email-quic_pragalla@quicinc.com/#r Possibly fuse needs some wake up tweaks due to its special scheduling requirements. Thanks, Miklos
Powered by blists - more mailing lists