From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f44.google.com (mail-dl1-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2855130F55F for ; Fri, 10 Apr 2026 00:47:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775782025; cv=none; b=MXRHPoMGEIowNy5/M0AqaX1+Snyh/30Makki5E7kS2ajSXgpXMkWjblC0mO+3H+qBKCzruBLQ4BSXtGYrQ8yPTtlXJ292ecNEp1AyPtg29E1THHhakWA9mFna2rLTNhunoafsd/JTG1OxLmy+RIFF+/yptfSTOdpfaTc3XwAByM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775782025; c=relaxed/simple; bh=5RSqm0i7TAMALBXs719N1oHBv8HwMRI4TbjdGJov0So=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=i2UJxL+0T1GsGExumLJQWvOBt1zOALiglaRsIOPLhgztz9joxu2zd0qHRe2O/ihvXDtWI88Dq65zQwNpHrzPyrkbvSH8pVhtlLZ8Y19Rtos/lOXhN7929cQOG1xeQGk962AQyj3+bTZGNpMvDKR/hnYSIfzUJKopgO6tvozRs/o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b=WL05AItd; arc=none smtp.client-ip=74.125.82.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b="WL05AItd" Received: by mail-dl1-f44.google.com with SMTP id a92af1059eb24-12c19d23b19so1494004c88.0 for ; Thu, 09 Apr 2026 17:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20251104.gappssmtp.com; s=20251104; t=1775782022; x=1776386822; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8dLqEnr+wCE0zIFZUjHqtBjKoRS3kf2QNeojFry0cDY=; b=WL05AItdw5GBbK/6YpQRx2xq0tzJP8x47J0Zbl8l/X8losGNzCSaDoSyBHSLagUmKC mzb0oB0nm33ulQ9luFZR3p1Yr36j8L0RJqDZRK2ZZxkZsukD3UvntYa0outb/ptdl6N3 VCav4Er0OTMZEdPtu77kKoTx4pNp1AtV8/mRCuIh7VrE5zLNmXYxU5eGpMOCBicwh7zA CnX5rlRaIXjywKFCfMd0niM4t0j8Ic7lfKwpLdqJoRE67IM+GLHz24BqQZGC7RurZsYS PLK9sOE/w8z8TwnJV2uE/fnpNYIxLGHADXziHF6Nub7ozUqrGfjIayp1KpM/YfWMgMhO aOfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775782022; x=1776386822; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8dLqEnr+wCE0zIFZUjHqtBjKoRS3kf2QNeojFry0cDY=; b=SdWjTGqHFS1ox5U/+WLvlgYZjqfrPIDQ1u716sQOWW7AHWJgklM15ZqmMv1mGsUD+W CUqkDIS6s5eVFJY3l73fsftLCjwEoQauY4PfTrq7X8msGpyH+JBWwI8lY57VCOrBxCSs oMJvJNETxGJ0mlGojH/zEZFClCLlbsrWG58mCBCxhmUQiQhL9Vp9vyZANKpXAFMSiDnV V0SBvCgn5uCmgPSWpbgNIO7J/KRfQK4NkViNdxojPcCLpB9sJYP0QjjYMiUIkde9ZY3z NKvPAo2cVNlbK6V1n5Ggzxy0GZR1zzA8Zt+32e+gG5K7yq3kjOfcT0Dl20U7hzqn22Wg TaSg== X-Forwarded-Encrypted: i=1; AJvYcCX9aN66D+ynfUpIpjfQJW7TxKhb+T0mSOjPdae7L96dCHILxsJ2GWDDAyXg78XYxTXf9ku1ekUM/VV+Mzw=@vger.kernel.org X-Gm-Message-State: AOJu0Yx7sL13OtVKh+ew8CdtKw3Ei76bwze3v7eDCf10TiY0Ez+3uKtO u0GNOglLx/jJ6ytWJoq/aCXuP10UmrlPChCJVQ+00lAbgG5xglMxwQI2fc1RPzXGR9A= X-Gm-Gg: AeBDietJL9rB8rHqMpLPtbIjS6wxU4NaGLeHsF1G1rYledBCh04PT50HGZFdy/XqnhV 8Gpkr3gRbCse0ghUQFwMpsOssDwQHbk9l3xi1znoQOFOjHDzBDgkcU+bY3Qiodi9ZOUNFPUf/Ke 44T22+finzxmxpWC9Wl5dcbA2e6j+hp4QJTFEAgDdDzEPvzwuWtUgS0/yFzoquJr72RgmQJhS1M E4q0y+jFXVuPZ0t7WstAZQEMguZknux+0Ajj+8FUUuKnfBIPRmM6DvKyY36a7eZ2Im8q2XaEdH1 dYb25OlsWKVlHf6Yhd5j2I6XZhIXZ4Fq6SqNAaPZmI5aNCgiCpmCJyjaXL1rvnrnl7QCw1LTGWm E4L7zgwjQhT8opALHXOgxXU3uuYyllbS88sjxaTOQ1RYqkRIkoFXS/9sHrSNiMhLYmyp/lASVQf DcjcVyqmS9nUMa7JLZTecN5LwQ7dSZN6SpbdlVZGYW7u9BIFIMgAwuYh6QdI25O4PSKRRqoMbDe cxrw1ZaDoZtLwpncMDAamvjAqMe35XfWUVHv6jn0MKGss2EhSoGWfQ= X-Received: by 2002:a05:7022:e986:b0:127:15cd:9f52 with SMTP id a92af1059eb24-12c34e37b1fmr652018c88.5.1775782021786; Thu, 09 Apr 2026 17:47:01 -0700 (PDT) Received: from ?IPV6:2600:380:873e:380f:e9e5:ea98:a905:9cbb? ([2600:380:873e:380f:e9e5:ea98:a905:9cbb]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12c34352490sm1530405c88.0.2026.04.09.17.46.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Apr 2026 17:47:01 -0700 (PDT) Message-ID: Date: Thu, 9 Apr 2026 18:46:54 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v4 1/3] block: add BIO_COMPLETE_IN_TASK for task-context completion To: Tal Zussman Cc: Matthew Wilcox , Christian Brauner , "Darrick J. Wong" , Carlos Maiolino , Alexander Viro , Jan Kara , Christoph Hellwig , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org References: <97b81868-6410-4c79-a242-679a9f04f073@columbia.edu> <95F28FA1-5CEF-4E80-BBB7-A429B4437D12@kernel.dk> <7e468bd2-e52b-4165-95c6-3f04e1dca21e@columbia.edu> Content-Language: en-US From: Jens Axboe In-Reply-To: <7e468bd2-e52b-4165-95c6-3f04e1dca21e@columbia.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/9/26 12:54 PM, Tal Zussman wrote: > > > On 4/8/26 7:36 PM, Jens Axboe wrote: >> On Apr 8, 2026, at 4:51?PM, Tal Zussman wrote: >>>> On 4/8/26 3:51 PM, Jens Axboe wrote: >>>>> On 4/8/26 12:?48 PM, Tal Zussman wrote: > On 3/25/26 4:?14 PM, Jens Axboe wrote: >>>>> >>>>> Thanks! I'm going to give Dave's llist suggestion a shot on top of >>>>> this as it seems like it'll simplify this nicely. Looks like that'll >>>>> involve turning bio::bi_next into a union with a struct llist_node. >>>> >>>> Since these lists can get long, I'd keep an eye on llist reversal >>>> overhead there... >>>> >>> >>> Going to send v5 shortly -- tested with and without the llist reversal and >>> it didn't seem to make much of a difference. This was on a single-disk VM >>> though, so any stress testing you could do would be very helpful. >>> >> >> With all due respect, a single test like that isn?t going to be that useful. I?d be wary of making that change willy nilly and just thinking ?it?s fine, worked fine on the one case I tested?. > > Understood -- unfortunately that's what I have access to at the moment. I > can requisition a machine with 2, maybe 3 disks, and test more thoroughly on > that before sending the next version, but that'll take a few days. You had > previously offered to test on your big box, so was hoping that was still on > the table :) I can do that, but I'm OOO for the next week, so won't be until I'm back. > (Although Christoph seems to have proposed moving away from llist again) I think that's a good idea, not a fan of using llist for this, in case that wasn't clear. These are per-cpu lists anyway, and having a constant overhead is better than needing to reverse an llist. IMHO. -- Jens Axboe