From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-2-16.ptr.blmpb.com (va-2-16.ptr.blmpb.com [209.127.231.16]) (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 7F66A41DE1B for ; Fri, 14 Aug 2026 07:50:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.231.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786693826; cv=none; b=b634kbgcOqkf9Hjq1f5tPwxUVFYIeK+tgNH6GNzV3RDJkTkFP0uFTSfZz8UjjbSxNdorcQNgUeW2/hrpY2GDw5GMwayfrokC/fNIfdBkPdJ2oK5BclaxuwXIbEqbS2KTcXSl7kxtioTijRbWqR12Y7+Sj3oiIw7YgDMCzJ+aljE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786693826; c=relaxed/simple; bh=Y2jZkZG5IdEinfxaABKa1bNtQfxrrDOJa1w7kxN9I5Y=; h=Content-Type:References:In-Reply-To:To:Message-Id:Mime-Version:Cc: From:Subject:Date; b=fKTX8MhZYb0Z3MJ16mXX/VqN7V4QHV2jYlSEOfXNlSfCw0HTjDemyOYWvanUJZCgXCw3TVqCdO/px+vBvzcHch1FuJn9mAucsWfQlwgWdKEP1ulMyZWuowhUwjno8vtNXsERk95gdNT04h5TcxLUZIkHwsv/zmFbzLx6exzWfYw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fnnas.com; spf=pass smtp.mailfrom=fnnas.com; dkim=pass (2048-bit key) header.d=fnnas-com.20200927.dkim.feishu.cn header.i=@fnnas-com.20200927.dkim.feishu.cn header.b=tMicTUuO; arc=none smtp.client-ip=209.127.231.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fnnas.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fnnas.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fnnas-com.20200927.dkim.feishu.cn header.i=@fnnas-com.20200927.dkim.feishu.cn header.b="tMicTUuO" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=s1; d=fnnas-com.20200927.dkim.feishu.cn; t=1786693810; h=from:subject:mime-version:from:date:message-id:subject:to:cc: reply-to:content-type:mime-version:in-reply-to:message-id; bh=JbnLgklqOUcOfZtgfE8qoZAa4WQi1t4pHM8VNSJ95PY=; b=tMicTUuOiAnfACj5gsLu2EuwligrANMVk06bL6KP2qysffPuym9ME8OeJa9s1ryfyvmDGz VbmjVCDrQ3uRh27kSYaMU44CusVoENs9K6NgPFUy0AAcxcdVvfbsDixLuOKbWeqT16/Usg hRg+WK8ne+oUiKyVqHULQ154YZzQIemikjiv2PLp2dA3Btk0BiOAGf9/YwxOfqE1dbCD4Z 4PCVF+zpQPVGPIU+I+rd6ImD0UtsTq9NQvK+7YGbloS6RExH3e0ZiynKp60W3taB97+b1L h0PAPy9+eZKu/lQbLDZ6dya3I6HsoA9pRMSZFbH43aHO2A24LWWgj/XSp2BKLQ== Reply-To: yukuai@fygo.io User-Agent: Mozilla Thunderbird Received: from [192.168.1.104] ([39.182.0.156]) by smtp.feishu.cn with ESMTPS; Fri, 14 Aug 2026 15:50:07 +0800 X-Lms-Return-Path: Content-Type: text/plain; charset=UTF-8 References: <20260811064744.1139446-1-yukuai@kernel.org> <20260811064744.1139446-3-yukuai@kernel.org> <20260814071232.GA9784@lst.de> In-Reply-To: <20260814071232.GA9784@lst.de> Content-Transfer-Encoding: quoted-printable To: "Christoph Hellwig" , "yu kuai" Message-Id: Precedence: bulk X-Mailing-List: linux-bcache@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Original-From: Yu Kuai Cc: "Jens Axboe" , "Tejun Heo" , "Josef Bacik" , "Johannes Weiner" , =?utf-8?q?Michal_Koutn=C3=BD?= , "Yu Kuai" , "Tao Cui" , "Jan Kara" , "Ming Lei" , "Jonathan Corbet" , "Shuah Khan" , "Coly Li" , "Kent Overstreet" , "Alasdair Kergon" , "Mike Snitzer" , "Mikulas Patocka" , "Benjamin Marzinski" , "Song Liu" , "Li Nan" , "Xiao Ni" , "Pankaj Gupta" , "Dan Williams" , "Vishal Verma" , "Dave Jiang" , "Alison Schofield" , "Ira Weiny" , "Andreas Gruenbacher" , "Matthew Wilcox" , "Andrew Morton" , "Chris Li" , "Kairui Song" , "Kemeng Shi" , "Nhat Pham" , "Baoquan He" , "Barry Song" , "Youngjun Park" , , , , , , , , , , , , From: "Yu Kuai" Subject: Re: [RFC PATCH v2 2/4] blk-cgroup: use a request_queue rhashtable for blkg lookup Date: Fri, 14 Aug 2026 15:50:04 +0800 Hi=EF=BC=8C =E5=9C=A8 2026/8/14 15:12, Christoph Hellwig =E5=86=99=E9=81=93: > On Tue, Aug 11, 2026 at 02:47:42PM +0800, Yu Kuai wrote: >> Keep q->blkg_list for ordered policy and scheduler walks. Initialize and >> destroy the hash with request_queue, and remove the radix-tree preload >> paths which are no longer needed. > Are these fast path operations? Otherwise we can walk all rhashtable > entries without an extra list, but it might be slower. All users are from sysfs/cgroupfs API, I think they can be considered slow = path, however currently spinlock is held in these procedures, I think it's better= to convert them to blkg_lookup based iterate after spinlock is converted to th= e blkcg_mutex. > >> @@ -191,10 +198,15 @@ static void blkg_release(struct percpu_ref *ref) >> { >> struct blkcg_gq *blkg =3D container_of(ref, struct blkcg_gq, refcnt); >> struct blkcg *blkcg =3D blkg->blkcg; >> int cpu; >> =20 >> + if (!list_empty(&blkg->q_node)) >> + WARN_ON_ONCE(rhashtable_remove_fast(&blkg->q->blkg_hash, >> + &blkg->q_hash_node, >> + blkg_hash_params)); >> + > The list_empty case is for initialization failure? Or can we end up > with that by other means? Yes, this is for initialization failure, blkg_alloc() failure after percpu_= ref_init(), or blkg_create() failure before rhashtable_insert succeed. > >> + * Lookup a blkg for the @blkcg - @q pair, whether it is online or dyin= g. >> + * >> + * Must be called in a RCU critical section. >> + */ > Please add must_hold and/or lockdep annotations for this instead of just > a comment. > > Also maybe mention that this does not acquire a reference and the caller > must already hold one? Perhaps it's more accurate that the blkg is pinned by IO or caller already hold one? > > --=20 Thanks, Kuai