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 X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2BE8BC432BE for ; Fri, 13 Aug 2021 02:59:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 471746104F for ; Fri, 13 Aug 2021 02:59:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 471746104F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C07518D0001; Thu, 12 Aug 2021 22:59:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB8DB6B0071; Thu, 12 Aug 2021 22:59:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA6898D0001; Thu, 12 Aug 2021 22:59:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id 912126B006C for ; Thu, 12 Aug 2021 22:59:30 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3053818030143 for ; Fri, 13 Aug 2021 02:59:30 +0000 (UTC) X-FDA: 78468551700.24.D605034 Received: from r3-17.sinamail.sina.com.cn (r3-17.sinamail.sina.com.cn [202.108.3.17]) by imf25.hostedemail.com (Postfix) with SMTP id 3C984B009FF8 for ; Fri, 13 Aug 2021 02:59:27 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([222.130.245.194]) by sina.com (172.16.97.27) with ESMTP id 6115E00A0000799A; Fri, 13 Aug 2021 10:59:25 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 73624449283476 From: Hillf Danton To: David Howells Cc: willy@infradead.org, trond.myklebust@primarydata.com, hch@lst.de, linux-nfs@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] mm: Fix NFS swapfiles and use DIO read for swapfiles Date: Fri, 13 Aug 2021 10:59:14 +0800 Message-Id: <20210813025914.2762-1-hdanton@sina.com> In-Reply-To: <162876946134.3068428.15475611190876694695.stgit@warthog.procyon.org.uk> References: <162876946134.3068428.15475611190876694695.stgit@warthog.procyon.org.uk> MIME-Version: 1.0 Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.17 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3C984B009FF8 X-Stat-Signature: 8xxb5e7kimwyu76ibia71x4cs4hit6y1 X-HE-Tag: 1628823567-910585 Content-Transfer-Encoding: quoted-printable 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 Thu, 12 Aug 2021 12:57:41 +0100 David Howells wrote: >=20 > Hi Willy, Trond, >=20 > Here's a change to make reads from the swapfile use async DIO rather th= an > readpage(), as requested by Willy. >=20 > Whilst trying to make this work, I found that NFS's support for swapfil= es > seems to have been non-functional since Aug 2019 (I think), so the firs= t > patch fixes that. Question is: do we actually *want* to keep this > functionality, given that it seems that no one's tested it with an upst= ream > kernel in the last couple of years? >=20 > I tested this using the procedure and program outlined in the first pat= ch. >=20 > I also encountered occasional instances of the following warning, so I'= m > wondering if there's a scheduling problem somewhere: >=20 > BUG: workqueue lockup - pool cpus=3D0-3 flags=3D0x5 nice=3D0 stuck for = 34s! > Showing busy workqueues and worker pools: > workqueue events: flags=3D0x0 > pwq 6: cpus=3D3 node=3D0 flags=3D0x0 nice=3D0 active=3D1/256 refcnt=3D= 2 > in-flight: 1565:fill_page_cache_func > workqueue events_highpri: flags=3D0x10 > pwq 3: cpus=3D1 node=3D0 flags=3D0x1 nice=3D-20 active=3D1/256 refcnt= =3D2 > in-flight: 1547:fill_page_cache_func > pwq 1: cpus=3D0 node=3D0 flags=3D0x0 nice=3D-20 active=3D1/256 refcnt= =3D2 > in-flight: 1811:fill_page_cache_func > workqueue events_unbound: flags=3D0x2 > pwq 8: cpus=3D0-3 flags=3D0x5 nice=3D0 active=3D3/512 refcnt=3D5 > pending: fsnotify_connector_destroy_workfn, fsnotify_mark_destroy_w= orkfn, cleanup_offline_cgwbs_workfn > workqueue events_power_efficient: flags=3D0x82 > pwq 8: cpus=3D0-3 flags=3D0x5 nice=3D0 active=3D4/256 refcnt=3D6 > pending: neigh_periodic_work, neigh_periodic_work, check_lifetime, = do_cache_clean > workqueue writeback: flags=3D0x4a > pwq 8: cpus=3D0-3 flags=3D0x5 nice=3D0 active=3D1/256 refcnt=3D4 > in-flight: 433(RESCUER):wb_workfn Is it a memory tight scenario that got rescuer active? > workqueue rpciod: flags=3D0xa > pwq 8: cpus=3D0-3 flags=3D0x5 nice=3D0 active=3D38/256 refcnt=3D40 > in-flight: 7:rpc_async_schedule, 1609:rpc_async_schedule, 1610:rpc_= async_schedule, 912:rpc_async_schedule, 1613:rpc_async_schedule, 1631:rpc= _async_schedule, 34:rpc_async_schedule, 44:rpc_async_schedule > pending: rpc_async_schedule, rpc_async_schedule, rpc_async_schedule= , rpc_async_schedule, rpc_async_schedule, rpc_async_schedule, rpc_async_s= chedule, rpc_async_schedule, rpc_async_schedule, rpc_async_schedule, rpc_= async_schedule, rpc_async_schedule, rpc_async_schedule, rpc_async_schedul= e, rpc_async_schedule, rpc_async_schedule, rpc_async_schedule, rpc_async_= schedule, rpc_async_schedule, rpc_async_schedule, rpc_async_schedule, rpc= _async_schedule, rpc_async_schedule, rpc_async_schedule, rpc_async_schedu= le, rpc_async_schedule, rpc_async_schedule, rpc_async_schedule, rpc_async= _schedule, rpc_async_schedule > workqueue ext4-rsv-conversion: flags=3D0x2000a > pool 1: cpus=3D0 node=3D0 flags=3D0x0 nice=3D-20 hung=3D59s workers=3D2= idle: 6 > pool 3: cpus=3D1 node=3D0 flags=3D0x1 nice=3D-20 hung=3D43s workers=3D2= manager: 20 > pool 6: cpus=3D3 node=3D0 flags=3D0x0 nice=3D0 hung=3D0s workers=3D3 id= le: 498 29 > pool 8: cpus=3D0-3 flags=3D0x5 nice=3D0 hung=3D34s workers=3D9 manager:= 1623 > pool 9: cpus=3D0-3 flags=3D0x5 nice=3D-20 hung=3D0s workers=3D2 manager= : 5224 idle: 859 >=20 > Note that this is due to DIO writes to NFS only, as far as I can tell, = and > that no reads had happened yet. >=20 > David > --- > David Howells (2): > nfs: Fix write to swapfile failure due to generic_write_checks() > mm: Make swap_readpage() for SWP_FS_OPS use ->direct_IO() not ->r= eadpage() >=20 >=20 > mm/page_io.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 67 insertions(+), 6 deletions(-) Print memory info to help understand the busy rescuer. +++ x/kernel/workqueue.c @@ -4710,12 +4710,16 @@ static void show_pwq(struct pool_workque } if (has_in_flight) { bool comma =3D false; + bool rescuer =3D false; =20 pr_info(" in-flight:"); hash_for_each(pool->busy_hash, bkt, worker, hentry) { if (worker->current_pwq !=3D pwq) continue; =20 + if (worker->rescue_wq) + rescuer =3D true; + pr_cont("%s %d%s:%ps", comma ? "," : "", task_pid_nr(worker->task), worker->rescue_wq ? "(RESCUER)" : "", @@ -4725,6 +4729,11 @@ static void show_pwq(struct pool_workque comma =3D true; } pr_cont("\n"); + if (rescuer) { + pr_cont("\n"); + show_free_areas(0, NULL); + pr_cont("\n"); + } } =20 list_for_each_entry(work, &pool->worklist, entry) {