From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CE7EC47DD9 for ; Wed, 27 Mar 2024 09:33:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 205F16B0092; Wed, 27 Mar 2024 05:33:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 18FED6B0093; Wed, 27 Mar 2024 05:33:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0096F6B0095; Wed, 27 Mar 2024 05:33:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D5F5B6B0092 for ; Wed, 27 Mar 2024 05:33:17 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9F38A80AD1 for ; Wed, 27 Mar 2024 09:33:17 +0000 (UTC) X-FDA: 81942305634.06.2A03F5E Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf11.hostedemail.com (Postfix) with ESMTP id 5C64240025 for ; Wed, 27 Mar 2024 09:33:15 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Vng5gi4s; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="7Xk/ghNk"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Vng5gi4s; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="7Xk/ghNk"; dmarc=none; spf=pass (imf11.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711531995; a=rsa-sha256; cv=none; b=oGNj5fhi2FcjYsP1TKuy9ye2937ce5zB6BVS7k5VVkWIFVXbffz3U5Wpzb7TcHCa18TPmf 4uMi2Lq0B9duKuGZoKnhuHtnqR+VnfSPAQonY50hucvGd1gN6M2Y1j8N/HoFVP11AnEbcH YgEk2SUtOe7uDK52xMK2LEyO6nXioDw= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Vng5gi4s; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="7Xk/ghNk"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Vng5gi4s; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="7Xk/ghNk"; dmarc=none; spf=pass (imf11.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711531995; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2Q1Gpg1vNXmP8CcxozlvISl2pAsCSU9f210dFyaw38Y=; b=LJzS8jXNUufrS/J++MMRgLFkjdxYjOf9JN5x3e9afKzhZpd0s6S9olokj9a3pXJZbtPQSf GwDSYm+n5LWAzXX7CCL6/97KPm07KfDPiAeucDJ5Aho1pp5dlzJ41CHXAhclnh1KnItRJ/ zRkWUXf/kcXYaxzZZNOKz1NT4x1eXSI= Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B5E21387EF; Wed, 27 Mar 2024 09:33:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1711531993; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2Q1Gpg1vNXmP8CcxozlvISl2pAsCSU9f210dFyaw38Y=; b=Vng5gi4sxoupKaSAG8p96Lfo9gIv+5sPUTQPFcXjd51APv0naDgto8X/CXP4Vn0eEnldRN OmWprAcUte9j+3pY8DG2XMwmy8diCh+5noU2wf2tiMVuWAREqQdImKhyZDjtJ8hvwuRT2/ bRUHzGaVReAdhwXyy+5EQ9LJ+Ojbqyk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1711531993; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2Q1Gpg1vNXmP8CcxozlvISl2pAsCSU9f210dFyaw38Y=; b=7Xk/ghNkRUjffJZlf7vWMhyMSAjGjn6Jwxmt3kO9g/cJONbTjb7YtOyl2mxqsv/ADShrDd W3wPWh6dShi509BQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1711531993; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2Q1Gpg1vNXmP8CcxozlvISl2pAsCSU9f210dFyaw38Y=; b=Vng5gi4sxoupKaSAG8p96Lfo9gIv+5sPUTQPFcXjd51APv0naDgto8X/CXP4Vn0eEnldRN OmWprAcUte9j+3pY8DG2XMwmy8diCh+5noU2wf2tiMVuWAREqQdImKhyZDjtJ8hvwuRT2/ bRUHzGaVReAdhwXyy+5EQ9LJ+Ojbqyk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1711531993; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2Q1Gpg1vNXmP8CcxozlvISl2pAsCSU9f210dFyaw38Y=; b=7Xk/ghNkRUjffJZlf7vWMhyMSAjGjn6Jwxmt3kO9g/cJONbTjb7YtOyl2mxqsv/ADShrDd W3wPWh6dShi509BQ== Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id A243613215; Wed, 27 Mar 2024 09:33:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap2.dmz-prg2.suse.org with ESMTPSA id m9dXJ9nnA2aXCgAAn2gu4w (envelope-from ); Wed, 27 Mar 2024 09:33:13 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 4566AA0812; Wed, 27 Mar 2024 10:33:09 +0100 (CET) Date: Wed, 27 Mar 2024 10:33:09 +0100 From: Jan Kara To: Kemeng Shi Cc: Tejun Heo , akpm@linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, willy@infradead.org, bfoster@redhat.com, jack@suse.cz, dsterba@suse.com, mjguzik@gmail.com, dhowells@redhat.com, peterz@infradead.org Subject: Re: [PATCH 6/6] writeback: remove unneeded GDTC_INIT_NO_WB Message-ID: <20240327093309.ejuzjus2zcixb4qt@quack3> References: <20240320110222.6564-1-shikemeng@huaweicloud.com> <20240320110222.6564-7-shikemeng@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5C64240025 X-Stat-Signature: 7t5s9osyjx3juxmw7fc61bn3395hu1oe X-HE-Tag: 1711531995-595942 X-HE-Meta: U2FsdGVkX1+K1QjNzSkrYtwHrNh7tZbfe82W5Zsha0QmC27VygDFW4qupZOAlmqRU5E4aygBzsM+QF3AJ6erZfmXMhcoTmqyrxOG7Brg4an7gEkoyVVn7H9S47OVqoldHQ+eREnDH2jhv8EvRwIrMnsNmVutqYdvuQDxkbjCCs3zzCZ7FzWL4lKusycJE274/msWlOYvdAPBGMQqu62K40jXOZY77K55Jkr8DKny25U3q1Pzplv5J7vAxpKL7mnsOV0JFFrPPJhtHGXyT0FltJCCbZB+88bRx/HF4Y10e4E8jxEue4pEXuEYDSATY3NKJaU3/n3Sg59nKATo+vYodL57smf19jCaHPZQjlamZee40mGp57GYLag6zpeqtUMx5yDMzuPFL5ZEiMn5ATib8Y4N7HifVpvxxMqJ6Necv47zG2M8QXdnj2nTolBcEBcdqlLiEmHr8sOYRkzpi1VfvZVJeZC6adH9CXmZAjYPgE+0q5WdkkgaR8pDeD4hqoOULxP59WzsnA3X6VjwTsw7y31cvyVOlTbXv7ONfTJiXIIugP/WQIkA9OQSMVj87Tgw6PRepgheNNGWWDIVTNyUhp7vzvA8k0cXB7cLGscKnZEi181iUJmk8CNFjgwJOl6Ckiw7pIPcMJ+s2gJ279b5cYHAOC8IuKL+QCQza3mx90QGk2PLUI7gg860/sndW645+pmIHOrbdbrhD1MfffBSui8XyKpBg+cW3UnAc6XtYXNXIYG0rFswW+QicoMVxqAj2CT5n8tpP6TNcCXEMQXUYpzme4t81tlxyjQi3BSdjSvZJl5GAwnq9Y3MekaqPS4hg1TlOAfwzJR0kGxxfY9hd50vQC2N66IJLDpdOXzbWK16nx8ALcYLEv0+YFLfQ1fPAOvUHHY2hHCDoYIBV2fDOxFLJHm+Xk2EVJipYDvZ3zQW9nBWQ1+15XnuEk6iMgMZc/emHT+SQMl14YeeQE+ m27CdLmQ MYslMdFI++EiddA176tTG+dmlOAnxCkU2wfTA06+bmCsnmvI4OtWTjXNSffE90xDcQhu+IhxKnoKIEy5mh002hTRG6Z8Sh8DcT5Nc2yEnNgVODoxve9XK7B+dihAaW4GUno8xZ2Nbni7e3WiBMafij8x/BFNbxATCFxHjNDcSvhOItbGRO1nonG925dFCaR4NnXrYT0lIsHgRmOWE8XVFWyDW/nRH0+MpmbCFf/Jt85Ya35tuyyP/MDR0NG++10asSiq+fGoAXXdfIlPgLpHTRvvFsFGBLZMZVDccNlD9Zh7Oo3TBIAnB2cmLhREtaid0+5m02c8cvY9kdl1XiYFGjp9uoRyR0CwvDNO2zkDOsVMKF5Y= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu 21-03-24 15:12:21, Kemeng Shi wrote: > > > on 3/20/2024 11:15 PM, Tejun Heo wrote: > > Hello, > > > > On Wed, Mar 20, 2024 at 07:02:22PM +0800, Kemeng Shi wrote: > >> We never use gdtc->dom set with GDTC_INIT_NO_WB, just remove unneeded > >> GDTC_INIT_NO_WB > >> > >> Signed-off-by: Kemeng Shi > > ... > >> void global_dirty_limits(unsigned long *pbackground, unsigned long *pdirty) > >> { > >> - struct dirty_throttle_control gdtc = { GDTC_INIT_NO_WB }; > >> + struct dirty_throttle_control gdtc = { }; > > > > Even if it's currently not referenced, wouldn't it still be better to always > > guarantee that a dtc's dom is always initialized? I'm not sure what we get > > by removing this. > As we explicitly use GDTC_INIT_NO_WB to set global_wb_domain before > calculating dirty limit with domain_dirty_limits, I intuitively think the > dirty limit calculation in domain_dirty_limits is related to > global_wb_domain when CONFIG_WRITEBACK_CGROUP is enabled while the truth > is not. So this is a little confusing to me. I'm not sure I understand your confusion. domain_dirty_limits() calculates the dirty limit (and background dirty limit) for the dirty_throttle_control passed in. If you pass dtc initialized with GDTC_INIT[_NO_WB], it will compute global dirty limits. If the dtc passed in is initialized with MDTC_INIT() it will compute cgroup specific dirty limits. Now because domain_dirty_limits() does not scale the limits based on each device throughput - that is done only later in __wb_calc_thresh() to avoid relatively expensive computations when we don't need them - and also because the effective dirty limit (dtc->dom->dirty_limit) is not updated by domain_dirty_limits(), domain_dirty_limits() does not need dtc->dom at all. But that is a technical detail of implementation and I don't want this technical detail to be relied on by even more code. What might have confused you is that GDTC_INIT_NO_WB is defined to be empty when CONFIG_CGROUP_WRITEBACK is disabled. But this is only because in that case dtc_dom() function unconditionally returns global_wb_domain so we don't bother with initializing (or even having) the 'dom' field anywhere. Now I agree this whole code is substantially confusing and complex and it would all deserve some serious thought how to make it more readable. But even after thinking about it again I don't think removing GDTC_INIT_NO_WB is the right way to go. Honza -- Jan Kara SUSE Labs, CR