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 1FBDCC7618E for ; Thu, 20 Apr 2023 20:24:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 99CAB900003; Thu, 20 Apr 2023 16:24:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 94D32900002; Thu, 20 Apr 2023 16:24:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81501900003; Thu, 20 Apr 2023 16:24:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 742C5900002 for ; Thu, 20 Apr 2023 16:24:15 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 240BAAC22E for ; Thu, 20 Apr 2023 20:24:14 +0000 (UTC) X-FDA: 80702896470.14.E6E7169 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf25.hostedemail.com (Postfix) with ESMTP id 47D49A0017 for ; Thu, 20 Apr 2023 20:24:11 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=VTaW3U7j; spf=pass (imf25.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682022252; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=XbIzxM2shVuTXnR29vOy8VrlUCteiWMqeXeOo/QS9Rg=; b=vfUerv1Q50UPNSf+gcT/3Z1rhTvQCtyGMr2yzx44BuitZwWZ8sRKx3lhjQ8ZqhDtWgJXWN h/LwVDcLhp+QJ29pNqyf24mj2ebylLkbZPs/uiPR/Mkqw4nb1ApmvXz2sngWmDUzUkklJv icJOjm41UlG0fZk13ZdKqlII2HDkUY0= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=VTaW3U7j; spf=pass (imf25.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682022252; a=rsa-sha256; cv=none; b=VpA6Ih2WtMogHDV6Bp/9imGSauGMZhdyvRGQRyAxY0UnPuLq94+vMOb/YxafZS1FuzIQT/ S75bUGMM3KMZv28mXrAMvkQovTQ01mSSxFv+zS2D6oT+zTFQ5D38RXSLA4jqEnxTeeFsY7 FR/Jk4r0b4bHaYHDuzXUQEO2BPnU06g= Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-94ef0a8546fso104063066b.1 for ; Thu, 20 Apr 2023 13:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1682022251; x=1684614251; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XbIzxM2shVuTXnR29vOy8VrlUCteiWMqeXeOo/QS9Rg=; b=VTaW3U7jSYhLPocSpczDYnca0rbAWGQgU2jjGGlWDIq5GGg1s2LuD56syxmIWB+6qR GCRzWrCkj7UaWW4VmeG1EDlGeA2cv5n6i+/1ZlmxgT8KbN4mV/xe61NzDcaW4rgYDkgm jHokeVXZP6pipdMf0KYcooTWmSNa+7hzYwjVBYtlvaK8xZd+wUfSZws1DmUuiXY7Zbw7 sBLoAcQ2EBQdn5Dl8NmHIWdrl8ZjowRpXxXgceiE5uvfZD8U7QlqDQvr7zKtIoo3yem0 cRMo4BXarqyRoyMm8OOAQ4Xxw847QScEkKKvvVSbe29ydE5meDqi4SZWKSGtKkSI4epK vLZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682022251; x=1684614251; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XbIzxM2shVuTXnR29vOy8VrlUCteiWMqeXeOo/QS9Rg=; b=AzZf7jxKcim0rrHQvJ7rlfvASUKCf91+rnwYtkdHaD/A2Np1qW+Ieh2Wjsvotkll0y JOBvfup984+8CXT3bMBafGjDT9bvJgV6H7Zt7xgJChgq+FAs1Iok70dJygmF1EQix1v+ q2ZM0HqnP64hPI19SLzUMGGu9HgytBIRM9UXVq6kpvLoCXm4agSQHHlXiDhXFGf8pUK5 IscHcheJsJsBipgSfSWTX+Prs9w09sn00V/a++sIwyVJ5ZCZTJ34HLDbk6Rr3yuxQEtX pgjsf/wksLUU1vz3NDeeWaUQ2pYDbTBkm8sT2FitDwqpFQJi0gO0dHxFVhmWDMabd2LJ 9+1w== X-Gm-Message-State: AAQBX9dXmOv6IgSJM/YH55WnB6pmGl0Uq8AR/Q81j9+6oc34Eq10iCaB h/oKSsvBFpOXRY/B2MC80je8Qkg3Djlw9qDKnOvoGQ== X-Google-Smtp-Source: AKy350YzP2DUqggsYt0ZcKkLG944feScSZjAPbMWQZcCGzSlr7o4ESqaB9KAAN7o5+mnXTfcXLI3Ws7U4tV4gtZ7zlc= X-Received: by 2002:a17:906:fcd4:b0:94f:50d:e16e with SMTP id qx20-20020a170906fcd400b0094f050de16emr241914ejb.12.1682022250565; Thu, 20 Apr 2023 13:24:10 -0700 (PDT) MIME-Version: 1.0 References: <20230403220337.443510-1-yosryahmed@google.com> <20230403220337.443510-2-yosryahmed@google.com> <7woe6ljcarqsr6uep7uns7bc3hm6xqog6ufk4rhwfo4vxixczw@tdjkdhx2euok> In-Reply-To: <7woe6ljcarqsr6uep7uns7bc3hm6xqog6ufk4rhwfo4vxixczw@tdjkdhx2euok> From: Yosry Ahmed Date: Thu, 20 Apr 2023 13:23:34 -0700 Message-ID: Subject: Re: [PATCH mm-unstable RFC 1/5] writeback: move wb_over_bg_thresh() call outside lock section To: =?UTF-8?Q?Michal_Koutn=C3=BD?= Cc: Alexander Viro , Christian Brauner , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 8asxp7j9wyfsarrz31zku59ywpd85sia X-Rspam-User: X-Rspamd-Queue-Id: 47D49A0017 X-Rspamd-Server: rspam06 X-HE-Tag: 1682022251-564523 X-HE-Meta: U2FsdGVkX1/FA0VXGE/Oyp7H5gEKQyvLs6v0NYzcE9Hel+1Gvf2agRARQ0Px7fwld3qzPZu7Plx9zFjarTz1CyrD2Yq19HJkW3i/MNTG3I1CfyVafvVcKIh1rY2Epw4OBM8ixUvoty5wRPkEjkEPcHFgMIsEzi2jgy+NmdCM461c0ex8WyC35W5kmQmocFZCmTTCVcXLKwxgIPp6giPC+xF9RPScAYuAmnG1DYAu8ZMYV2zN53sjGCRF0hSEBy405zKNeYULI0+gmu9DXSS2x/ECykD+3vIDFR3Ec3Eijpdm+O5nzjP2TJrZxX6dvv0r3AaaRUEpsSYnktij2tj/CJsR0t1BujMoDx8njpyAHEyGFme/XqVZ7inn/oxqlh5eSLY6zfjWBggBQPw1fqSaqINO2tui2+lRjVye0rIZSJ0HrRMAAAmStv90Ef2HQ3/LP77c/1Od9WwbpDbtneMPl5AjNFAJWmvQTQ9mbvhiXqUp02OpRi3gQkC7I+zZWjsgZShvWqheG8Efxlr9GfBUdr3CukIFgb6s+0GI8lHKINOqgjXKnCjN2WUHQ8ZD85ZagIulHX2IsmuTbhIO2UAAhd6n609SyrhCaD7YTRWavZQD6VHgSeiLrfMZH70Yrg1SqR3zbV6mofU2lGwPAGAuN9mvPOL6EsruPdp8vhc7ozM0HHvy3noOfeV3sUq8t/nFbr9RzpZh9SBcyZycU5bhVyeD8a0unDYN5eztXa5/ix2CRJ5AFZAR3lM49ZsvGneXRXMuWNEVvYBS8P9raqL2Evcdx/fZ6ZdeCcy80IFFWo39VbAB1Abpqb+8UMrdGA8C49RJH5fWD3nftaEGkOXWBG7AbiZRMMHCzBdA2720fVQev1tT3AsUrr4GfdDxf095f3Edu7Xv0g3AKFJZfZ4dXGeFwRXUzzS8NjKW/jp83Iu45SNPuY3zuCpR7vW7pLYnt2D+Ch6p307y/aEZ2jw 66ZDxTO7 CWBcoNF1n8jhwTmXzfCHB5QGiykaKgaJYXACuFlZC7VmORkB2g2FCSqkCZ0XG0C/CdJllsgXXs8XJkErGjKx413qQnowlz21+yHrmz1SSA3qTX7IOWOjrc61DfnJljIadgZ0vy2hz1ommYp0vIpxL6bjudLcxxNZcpNC1C3EPBtWjxjr37QRuP4iztVKz/1BJ+uUiWRaRF4cjkZlOeEvHH6Bg+p76Zdivjqv7um2ol02qwwpdSfB9LCCDq6hSjZiVCZQKNhkyuFfaCGVmzbsZ87PbmUIRtRKAgJnxKSaevaP7ntV6x59E11yqcSeb4vuXLky4vbmfHugWlY9w5TMhz5Vy+XwoRABpC+MuP8Ach7kYKqw= 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: On Wed, Apr 19, 2023 at 4:38=E2=80=AFAM Michal Koutn=C3=BD wrote: > > On Mon, Apr 03, 2023 at 10:03:33PM +0000, Yosry Ahmed wrote: > > wb_over_bg_thresh() calls mem_cgroup_wb_stats() which invokes an rstat > > flush, which can be expensive on large systems. Currently, > > wb_writeback() calls wb_over_bg_thresh() within a lock section, so we > > have to make the rstat flush atomically. On systems with a lot of > > cpus/cgroups, this can cause us to disable irqs for a long time, > > potentially causing problems. > > > > Move the call to wb_over_bg_thresh() outside the lock section in > > preparation to make the rstat flush in mem_cgroup_wb_stats() non-atomic= . > > The list_empty(&wb->work_list) should be okay outside the lock section > > of wb->list_lock as it is protected by a separate lock (wb->work_lock), > > and wb_over_bg_thresh() doesn't seem like it is modifying any of the b_= * > > lists the wb->list_lock is protecting. Also, the loop seems to be > > already releasing and reacquring the lock, so this refactoring looks > > safe. > > > > Signed-off-by: Yosry Ahmed > > --- > > fs/fs-writeback.c | 16 +++++++++++----- > > 1 file changed, 11 insertions(+), 5 deletions(-) > > > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > > index 195dc23e0d831..012357bc8daa3 100644 > > --- a/fs/fs-writeback.c > > +++ b/fs/fs-writeback.c > > @@ -2021,7 +2021,6 @@ static long wb_writeback(struct bdi_writeback *wb= , > > struct blk_plug plug; > > > > blk_start_plug(&plug); > > - spin_lock(&wb->list_lock); > > for (;;) { > > /* > > * Stop writeback when nr_pages has been consumed > > @@ -2046,6 +2045,9 @@ static long wb_writeback(struct bdi_writeback *wb= , > > if (work->for_background && !wb_over_bg_thresh(wb)) > > break; > > > > + > > + spin_lock(&wb->list_lock); > > + > > /* > > * Kupdate and background works are special and we want t= o > > * include all inodes that need writing. Livelock avoidan= ce is > > @@ -2075,13 +2077,19 @@ static long wb_writeback(struct bdi_writeback *= wb, > > * mean the overall work is done. So we keep looping as l= ong > > * as made some progress on cleaning pages or inodes. > > */ > > - if (progress) > > + if (progress) { > > + spin_unlock(&wb->list_lock); > > continue; > > + } > > + > > This would release wb->list_lock temporarily with progress but that's > already not held continuously due to writeback_sb_inodes(). > Holding the lock could even be shortened by taking it later after > trace_writeback_start(). > > Altogether, the change looks OK, > Reviewed-by: Michal Koutn=C3=BD Thanks for taking a look! >