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=-3.5 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 04283C433DF for ; Wed, 3 Jun 2020 13:39:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B35CB20738 for ; Wed, 3 Jun 2020 13:39:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B35CB20738 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 369EE80007; Wed, 3 Jun 2020 09:39:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3408C8E0006; Wed, 3 Jun 2020 09:39:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 257AB80007; Wed, 3 Jun 2020 09:39:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id 0D40F8E0006 for ; Wed, 3 Jun 2020 09:39:52 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C5EE3204AC for ; Wed, 3 Jun 2020 13:39:51 +0000 (UTC) X-FDA: 76888008582.02.meal34_55e86ec7dca3f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id AB19A1F848 for ; Wed, 3 Jun 2020 13:39:51 +0000 (UTC) X-HE-Tag: meal34_55e86ec7dca3f X-Filterd-Recvd-Size: 4487 Received: from r3-25.sinamail.sina.com.cn (r3-25.sinamail.sina.com.cn [202.108.3.25]) by imf44.hostedemail.com (Postfix) with SMTP for ; Wed, 3 Jun 2020 13:39:49 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([221.219.1.77]) by sina.com with ESMTP id 5ED7A82100037B46; Wed, 3 Jun 2020 21:39:47 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 14105954920186 From: Hillf Danton To: "Ahmed S. Darwish" Cc: Sebastian Andrzej Siewior , LKML , linux-mm , Konstantin Khlebnikov , Peter Zijlstra , Thomas Gleixner Subject: Re: [RFC PATCH] mm: swap: remove lru drain waiters Date: Wed, 3 Jun 2020 21:39:35 +0800 Message-Id: <20200603133935.11084-1-hdanton@sina.com> In-Reply-To: <20200603102412.GA1030128@debian-buster-darwi.lab.linutronix.de> References: <20200601143734.9572-1-hdanton@sina.com> <20200603082145.jfgmzozx42rjxegx@linutronix.de> MIME-Version: 1.0 X-Rspamd-Queue-Id: AB19A1F848 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 3 Jun 2020 12:24:12 +0200 "Ahmed S. Darwish" wrote: > On Wed, Jun 03, 2020 at 10:21:45AM +0200, Sebastian Andrzej Siewior wro= te: > > On 2020-06-01 22:37:34 [+0800], Hillf Danton wrote: > > > > > > After updating the lru drain sequence, new comers avoid waiting for > > > the current drainer, because he is flushing works on each online CP= U, > > > by trying to lock the mutex; the drainer OTOH tries to do works for > > > those who fail to acquire the lock by checking the lru drain sequen= ce > > > after releasing lock. > > > > > > See eef1a429f234 ("mm/swap.c: piggyback lru_add_drain_all() calls") > > > for reasons why we can skip waiting for the lock. > > > > > > The memory barriers around the sequence and the lock come together > > > to remove waiters without their drain works bandoned. > > > > > > Cc: Sebastian Andrzej Siewior > > > Cc: Konstantin Khlebnikov Cc: Ahmed S. Darwish > > > Signed-off-by: Hillf Danton > > > --- > > > This is inspired by one of the works from Sebastian. > > This is inspired by one of the works from Ahmed https://lore.kernel.org/linux-mm/20200519214547.352050-3-a.darwish@linu= tronix.de/ > > > > > --- a/mm/swap.c > > > +++ b/mm/swap.c > > > @@ -714,10 +714,11 @@ static void lru_add_drain_per_cpu(struct > > > */ > > > void lru_add_drain_all(void) > > > { > > > - static seqcount_t seqcount =3D SEQCNT_ZERO(seqcount); > > > + static unsigned int lru_drain_seq; > > > static DEFINE_MUTEX(lock); > > > static struct cpumask has_work; > > > - int cpu, seq; > > > + int cpu; > > > + unsigned int seq; > > > > > > /* > > > * Make sure nobody triggers this path before mm_percpu_wq is ful= ly > > > @@ -726,18 +727,16 @@ void lru_add_drain_all(void) > > > if (WARN_ON(!mm_percpu_wq)) > > > return; > > > > > > - seq =3D raw_read_seqcount_latch(&seqcount); > > > + lru_drain_seq++; > > > + smp_mb(); > > > > > > - mutex_lock(&lock); > > > +more_work: > > > > > > - /* > > > - * Piggyback on drain started and finished while we waited for lo= ck: > > > - * all pages pended at the time of our enter were drained from ve= ctors. > > > - */ > > > - if (__read_seqcount_retry(&seqcount, seq)) > > > - goto done; > > > + if (!mutex_trylock(&lock)) > > > + return; > > > >=20 > The patch I've posted makes sure to preserve the existing draining > logic. It only fixes an erroneous usage of seqcount_t latching, plus a > memory barriers bugfix, found by John, and is to be included in v2: >=20 > https://lkml.kernel.org/r/87y2pg9erj.fsf@vostro.fn.ogness.net Thanks for your link. >=20 > On the other hand, you're making the draining operation completely > asynchronous for a number of callers. This is such a huge change, and I > fail to see: 1) any rationale for it in the changelog, The changlog does not match the change. It is based on my understanding that percpu pagevec is itself in nature async operation. The introduction of seqcount casts a shaft of light on making lru drain async without any individual drain work lost. > 2) whether it's been verified that call-sites won't be affected. No. It's 10x harder than s/lock/trylock/, you see. Hillf