From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) (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 4DB253769F3 for ; Fri, 22 May 2026 22:47:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.139.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779490075; cv=none; b=WoQfY9d+Ud9EOdYHVOsxHKStwB+9XXsAYBDk0SKRp0StVcopVRHMDkdBO2tG8yRuSjz1Zcf3v5oGsPPwQcKI4/7DscGaMoUlfeSAdrLZHvrLIDESMWKjHDBRyz5jFHIgDO2TCi+BA1u4KU3lMG2mWZXzdsxq2JAE+c0lRqssYq4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779490075; c=relaxed/simple; bh=uoKzIXGyLSdhgTaP6+mkc6gT7TgNsg+NqAIq/YBaHoI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jQGRLpdB8fu8DG9LVoLXE4+0rnzTiHasl4BIUcHVM60AVGp6J8AXTCKWJ5eLjRRp1IATs+YzNNBiUsQpvaoFNl4EV8Tq5880bwo28LM7fBBQvy2o7/ENcvrbgNSHAPtfw7pX8ja7g6UziTPBzwWwhObAKbz8PKCaQf58u9XEZko= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=columbia.edu; spf=pass smtp.mailfrom=columbia.edu; dkim=pass (2048-bit key) header.d=columbia.edu header.i=@columbia.edu header.b=vFpYLWSb; arc=none smtp.client-ip=148.163.139.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=columbia.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=columbia.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=columbia.edu header.i=@columbia.edu header.b="vFpYLWSb" Received: from pps.filterd (m0167074.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 64MMRgPc874418 for ; Fri, 22 May 2026 18:47:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pps01; bh=TT8g lPTJWpZIUOrxyHUumKTmUNTeW5g1ZoNuE+A9ihg=; b=vFpYLWSbBpFKJ85ciFEi u2SR/IdqoXjnN6kLyLFAjIYNXlFduNAnKzlEOJyqebGO0BXFOXjsCKKQJvRpDhUH aUpuTGjW4y5shIkVkdDenX3gvbQPh7KZhgEc7Hc9vmM/v9gxlvZ3XsuWfoK58UbO vrXMR30AVDvhb9znjiDddAxgzDhPpb0AbCsj0BEwoahpaDGgnCWx3G+WBTDbFEXh YAtoaNiOY/hYZBSdZmzrj4AAJ4rTdfh2MY+l1WWXcYKdOY+FTwg32JJcgVrKzrxm fz3jOddrfZIJJZdVvcWgGxEk0/qjEKpkEhlr2iPrthjaCzM9KuhM1MTjfH79+HsB /Q== Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by mx0b-00364e01.pphosted.com (PPS) with ESMTPS id 4eat0haruq-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 22 May 2026 18:47:46 -0400 (EDT) Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-516879bf1a7so207088271cf.1 for ; Fri, 22 May 2026 15:47:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779490066; x=1780094866; 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=TT8glPTJWpZIUOrxyHUumKTmUNTeW5g1ZoNuE+A9ihg=; b=qQD5aGIOl+NMd+ueKK2GZxQ129oUi0DbC1oj9W31u6upVovep6wl17pMKhAl2ds1wu iUI9LXeeVGwaYLBiUsIRpjy3PBxPynoHLPuDb0JM1GffqSJuW+nomQOPdOp0i2nNtpvJ xSNw5FhOjxJORAzH7yZfSYA9SV7HU4T5srB32tdztWy52Tftg/4QXCak2RC6p1obg1Jn FcFLZwuXQkfEMaiGQWr65YubqqEMAmsJtRVRA8oxC5Y3sNR4JUGOGjpKhth6Wo4VCGGO RVsU97rK+qF2cRdS6+4OD9VGMF/oUPeRjerx0rd23f0cElWJl82deIyhqifYOKjV/BpO rt8A== X-Forwarded-Encrypted: i=1; AFNElJ+KhSIE3eTi+Wj5RmC0L2zaG1klQ1BlHm0lDge5Fu0tEswgHu64JPlEZU+fsuuD3DRczBllJztG2R03XRM=@vger.kernel.org X-Gm-Message-State: AOJu0YxLhz+Wk3tyAmwsICDdjJR9U0AR+ER+2zXb/gj5fpkdEArBOskY s9WP+3FZFpK4mnPdpd4TD5PzAPjlFYwMP3ZaMvNLy403Pd6nuni/DX54S0B4b8S6fPfVf7YOljj LqL1/rG4MygcyJCkHKTF+FRJOo6mTVVYseL5AjLrlEPOkSaMx7XYLO5lUO+GY4Q== X-Gm-Gg: Acq92OGGffbVtqhm58H3djdW+gE6lfiAjM+B5JfMbPW+h/Y6cO5z48iEtLxl4dzbvo1 KnmoohvsCT17aNEsMtwC0h+MOiebJawlu/qDGEdIuzZCNZ54qQ3rq6qGELxqzrOyWxXMR4mCjaG CyrvB/uTsEryYNyK5YG4n5XVwxu80VyBfSvtpwZ9zrxIhpplVl664AiqPw7TgVW/HYz0qt5i2s/ U6SwLwd6G1Nq/JJCC7NFAPYJzKVfZ5W2u31LvUl4KTmgZAj4RHvHyYn0nUbjnQ034qpLzpRlfNR kelRjdQ44QC7aYZoUDh44XPjOmoAqaGsT6TGxmbk4oCtvTCvIuwIdudhGrfCjbHzxEzLZSmW2jd 8qP27rUF8rDKfdzaH+EdtlUv7XoB2tXxNaQuPFBjPZ9ajIQ9r/QMUgwe500wIE7Rn7PLO967AyX mO87KCA5AgWA== X-Received: by 2002:a05:622a:647:b0:50d:987c:8174 with SMTP id d75a77b69052e-516c54ce3famr103506881cf.4.1779490065818; Fri, 22 May 2026 15:47:45 -0700 (PDT) X-Received: by 2002:a05:622a:647:b0:50d:987c:8174 with SMTP id d75a77b69052e-516c54ce3famr103506511cf.4.1779490065251; Fri, 22 May 2026 15:47:45 -0700 (PDT) Received: from [10.207.65.224] (nat-128-59-177-214.net.columbia.edu. [128.59.177.214]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-516d8b00143sm26022671cf.3.2026.05.22.15.47.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 May 2026 15:47:44 -0700 (PDT) Message-ID: Date: Fri, 22 May 2026 18:47:43 -0400 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 v6 1/4] block: add task-context bio completion infrastructure To: Christoph Hellwig Cc: Jens Axboe , "Matthew Wilcox (Oracle)" , Christian Brauner , "Darrick J. Wong" , Carlos Maiolino , Alexander Viro , Jan Kara , Dave Chinner , Bart Van Assche , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Gao Xiang References: <20260514-blk-dontcache-v6-0-782e2fa7477b@columbia.edu> <20260514-blk-dontcache-v6-1-782e2fa7477b@columbia.edu> Content-Language: en-US From: Tal Zussman In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: 02O4qTBveKfHdkn8897bxCTYhSDd4GWl X-Authority-Analysis: v=2.4 cv=f6l4wuyM c=1 sm=1 tr=0 ts=6a10dd12 cx=c_pps a=JbAStetqSzwMeJznSMzCyw==:117 a=n4JpGxNP30DHW88kdRRHAg==:17 a=IkcTkHD0fZMA:10 a=NGcC8JguVDcA:10 a=x7bEGLp0ZPQA:10 a=VkNPw1HP01LnGYTKEx00:22 a=Da8U98TiO7q1upZEImrf:22 a=azVShVRs0zEubeQ0wG0L:22 a=76MgQrUCaxHmrnKOjHwA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=uxP6HrT_eTzRwkO_Te1X:22 X-Proofpoint-GUID: 02O4qTBveKfHdkn8897bxCTYhSDd4GWl X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNTIyMDIyNyBTYWx0ZWRfX2PFaToA7R5lg AmGKS01gaRMHSGsq+8KH2M3+HAyzLP3MGVz5iPqG5tHkdcud6Rj2wJT/9uR/MKxnzrzvEMEdI0c TtJ86gWBlqiAptKNePmK7vJr1swVdK6e+6rdvfs+JDDJM60PM0RdJWtzCfpZ/GdhOmL8YWMzFfd dlO/NGzdig4Fg0UGoQuI5cuyjBTIl1SXn4o31VmL9vnbhhdfuPViOCJDbO+X9tDTew6W2KFZsPg VH8deDdNcehuqYdVrkl868/PRof3xkHoB44I6hcs6z2AWjgPNbnL0iNIyJGNQTB/+eeGn8vLLZU XcsDca3ilgCOPggHMSMYuMdMgW1vk6cXJl5jFo3kJA0lIIo9eYcnUoBM+j+qKfxTNT555w3X+Qp Oz95QPnxT96wY4PiYH2e+CZfsZjJPKI8BwKsmvHbgwLFOHlsJcAG3ftFo8aW119U+jimTvIe9QH 6ff0Sn0ISvT6lDh+okw== X-Proofpoint-Virus-Version: vendor=nai engine=6900 definitions=11794 signatures=596817 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 spamscore=0 clxscore=1015 impostorscore=10 malwarescore=0 lowpriorityscore=10 bulkscore=10 suspectscore=0 priorityscore=1501 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2605130000 definitions=main-2605220227 On 5/18/26 2:48 AM, Christoph Hellwig wrote: > On Thu, May 14, 2026 at 05:51:14PM -0400, Tal Zussman wrote: >> Some bio completion handlers need to run from preemptible task context, >> but bio_endio() may be called from IRQ context (e.g., buffer_head >> writeback). Callers need a way to ensure their callback eventually runs >> from a sleepable context. Add infrastructure for that, in two forms: >> >> 1. BIO_COMPLETE_IN_TASK, a bio flag the submitter sets when it knows >> in advance that its callback needs task context (e.g., dropbehind >> writeback). bio_endio() sees the flag and offloads completion to a >> worker automatically. >> >> 2. bio_complete_in_task(), a helper that completion callbacks can >> invoke from within bi_end_io() when the deferral decision is >> dynamic (e.g., fserror reporting). > > Note that method 2 is unused as of this series. I do plan to add users > ASAP, and at one or two could even land through the block layer in this > merge window. > >> Both share a per-CPU batch list drained by a delayed work item on a >> WQ_PERCPU workqueue. Producers push the bio onto the local CPU's batch >> and schedule the work item, which then dispatches each bio's bi_end_io() >> from task context. The delayed work item uses a 1-jiffie delay to allow >> batches of completions to accumulate before processing. > > But this 1-jiffie delay also means we unconditionally increase > completion latency, which feels like a bad idea. Do you have any > measurements that show where it does benefit? Note that queing work > already often has very measurable latency on it's own. This also > directly contradics the erofs experience that even went to a RT > thread to reduce the latency. I added this per Dave's feedback on v4, where he noted that XFS inodegc uses a delayed work item to avoid context switch storms. There's only a delay for the first bio in a batch to complete, as we only delay when the list is empty. I'll run some experiments and measure context switches, completion latency, etc. to see if this is necessary. >> Both methods are gated on bio_in_atomic(), which returns true in any >> context where a sleeping bi_end_io() is unsafe, including >> non-preemptible task context. This logic is copied from commit >> c99fab6e80b7 ("erofs: fix atomic context detection when >> !CONFIG_DEBUG_LOCK_ALLOC"). > > Let's not copy it, but have a prep patch that moves the erofs logic > into the block layer under the new bio_in_atomic name. Will do. >> + while ((bio = bio_list_pop(&list))) >> + bio->bi_end_io(bio); >> + >> + if (need_resched()) { >> + bool is_empty; >> + >> + local_lock_irq(&bio_complete_batch.lock); >> + is_empty = bio_list_empty(&batch->list); >> + local_unlock_irq(&bio_complete_batch.lock); >> + if (!is_empty) >> + mod_delayed_work_on(batch->cpu, >> + bio_complete_wq, >> + &batch->work, 0); >> + break; >> + } >> + } > > Ån all mainstream architetures we now default to lazy preempt, which > should remove the need for need_resched() calls. Do you have evidence > that we actually need this handling on recent kernels? No evidence - I added this per feedback on v3, but agreed that it can be simplified. > Otherwise this looks good to me. > Thanks - AI review found a couple more small things, which I'll respond to in a separate message.