From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp06-ext.udag.de (smtp06-ext.udag.de [62.146.106.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA16E315D40; Fri, 6 Mar 2026 08:17:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.146.106.76 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772785045; cv=none; b=gDDSe1u30GEgVdbgY+k1vAhbIhclI/vnNhDdn5nT6cUsgHbbcOAMoNNeTMTTrldi5a7CEf1RKbGLl3uHuXsbZsbEeu8L4rE4zxwEhaCJUmlb/YDsUGiJFziKLmF/9YOu576nWJu8Yo6aeZUTO7kVO60wPABbSbeUeBzU+vk6D8Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772785045; c=relaxed/simple; bh=IKmuCai+kYoVonCzcAEr2NYIzjK+3Gqf5dNNhPwDpYE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=j/bQqwJ12jOmU1x/68zDawQ5zPOQfXA+Ouat6dWDvPil24btLrNk2xXOCdJxMk8YGAaeDWVeAqTLt1HSr100WXmzm+7etRskDNikgAYkBN6i0uiGP7pCyTRPtvVD0p3lXP2JfOAmBTC8d231yJa7SB8GFDlZHYjo4o1FSd+QBlA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=birthelmer.de; spf=pass smtp.mailfrom=birthelmer.de; arc=none smtp.client-ip=62.146.106.76 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=birthelmer.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=birthelmer.de Received: from localhost (200-143-067-156.ip-addr.inexio.net [156.67.143.200]) by smtp06-ext.udag.de (Postfix) with ESMTPA id 8468AE01BB; Fri, 6 Mar 2026 09:17:14 +0100 (CET) Authentication-Results: smtp06-ext.udag.de; auth=pass smtp.auth=birthelmercom-0001 smtp.mailfrom=horst@birthelmer.de Date: Fri, 6 Mar 2026 09:17:13 +0100 From: Horst Birthelmer To: Joanne Koong Cc: Bernd Schubert , Miklos Szeredi , Horst Birthelmer , Bernd Schubert , Luis Henriques , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Horst Birthelmer Subject: Re: Re: Re: Re: [PATCH v5 1/3] fuse: add compound command to combine multiple requests Message-ID: References: Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Mar 05, 2026 at 04:52:01PM -0800, Joanne Koong wrote: > On Sat, Feb 14, 2026 at 9:51 AM Horst Birthelmer wrote: > > > > On Fri, Feb 13, 2026 at 05:35:30PM -0800, Joanne Koong wrote: > > > On Thu, Feb 12, 2026 at 3:44 AM Horst Birthelmer wrote: > > > > I have a feeling we have different use cases in mind and misunderstand each other. > > > > > > > > As I see it: > > > > From the discussion a while ago that actually started the whole thing I understand > > > > that we have combinations of requests that we want to bunch together for a > > > > specific semantic effect. (see OPEN+GETATTR that started it all) > > > > > > > > If that is true, then bunching together more commands to create 'compounds' that > > > > semantically linked should not be a problem and we don't need any algorithm for > > > > recosntructing the args. We know the semantics on both ends and craft the compounds > > > > according to what is to be accomplished (the fuse server just provides the 'how') > > > > > > > > From the newer discussion I have a feeling that there is the idea floating around > > > > that we should bunch together arbitrary requests to have some performance advantage. > > > > This was not my initial intention. > > > > We could do that however if we can fill the args and the requests are not > > > > interdependent. > > > > > > I have a series of (very unpolished) patches from last year that does > > > basically this. When libfuse does a read on /dev/fuse, the kernel > > > crams in as many requests off the fiq list as it can fit into the > > > buffer. On the libfuse side, when it iterates through that buffer it > > > offloads each request to a worker thread to process/execute that > > > request. It worked the same way on the dev uring side. I put those > > > changes aside to work on the zero copy stuff, but if there's interest > > > I can go back to those patches and clean them up and put them through > > > some testing. I don't think the work overlaps with your compound > > > requests stuff though. The compound requests would be a request inside > > > the larger batch. > > > > I would like to have your patch for the processing of multiple requests > > and the compound for handling semantically related requests. > > > > the kernel-side changes for the /dev/fuse request batching are pretty > self-contained [1] but the libfuse changes are very ugly. The > benchmarks didn't look promising. I think it only really helps if the > server has metadata-heavy bursty behavior that saturates all the > libfuse threads, but I don't think that's typical. I dont think it's > worth pursuing further. Thanks for the patch. I agree completely. However I wrote that in the context where I thought that people wanted to achieve something different with compound requests, like processing parts of a queue depending on some or no criteria. That's why I stressed the semantic relation of the requests in a compound. I'm almost willing to bet that in the future we will see someone get the idea of LOOKUP+OPEN+READ+CLOSE, which would practically create exactly those bursts when not done as a compound. Just as a side note ... > > Thanks, > Joanne > > [1] https://github.com/joannekoong/linux/commit/308ebbde134ac98d3b3d3e2f3abc2c52ef444759