From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31539 invoked from network); 19 Jan 2022 10:02:58 -0000 Received: from 4ess.inri.net (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 19 Jan 2022 10:02:58 -0000 Received: from simple-cc.org ([81.4.111.230]) by 4ess; Wed Jan 19 02:51:56 -0500 2022 Received: from localhost (simple-cc.org [local]) by simple-cc.org (OpenSMTPD) with ESMTPA id 8b6a6aa5 for <9front@9front.org>; Wed, 19 Jan 2022 08:51:49 +0100 (CET) Date: Wed, 19 Jan 2022 08:51:49 +0100 From: "Roberto E. Vargas Caballero" To: 9front@9front.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: stable progressive base browser Subject: Re: [9front] Re: devfs performance Reply-To: 9front@9front.org Precedence: bulk Hi, On Mon, Jan 17, 2022 at 04:27:51PM +0100, Martijn Heil wrote: > In the meantime I've started writing an (experimental) patch for > devfs, that should at least work for my use if I succeed. I'll gladly > share it if I consider it anywhere near worthy, but considering my > inexperience with this kernel development I have no expectations. > Nonetheless I'll try my best. > > In case anyone is interested in the technical details; > Block-interleaved I/O is handled by interio() at /sys/src/9/port/devfs:1134. > This in turn synchronously calls the blocking io() located at > /sys/src/9/port/devfs:1031 for each sequential block to read from the > inner devices. I have interleaving in my disk configuration, and I thought that the access was done in parallel. I think we should take a deep look to your patch because otherwise the interleaving configuration does not make sense. Regards,