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 CDA13C433F5 for ; Fri, 13 May 2022 15:19:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 54BC46B0073; Fri, 13 May 2022 11:19:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FB146B0075; Fri, 13 May 2022 11:19:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39BB28D0001; Fri, 13 May 2022 11:19:24 -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 26A6A6B0073 for ; Fri, 13 May 2022 11:19:24 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E570C322AE for ; Fri, 13 May 2022 15:19:23 +0000 (UTC) X-FDA: 79461078606.06.D1F8A42 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 82FA11400A5 for ; Fri, 13 May 2022 15:19:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652455162; h=from:from: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; bh=N6V1NExxHFVotsL8cfWpcK7gAhNvrYJpQx9tmGQ95Dc=; b=Yp84L6YDitHJzcIgw+oNst45bzisGHDv0fRhfwZg//vwKytjHOkgXOygUUghdaqL9LgJjm GoCkgLg2DYKlijMaVlkRLOfQSGjCpQbHhPjoZwc0WmEr+HFEf2jlKoyAFVdseW/qxS6hUS jSOTu2m0yHnAQFKtiBXYZOOFxIrBdxc= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-263-QlzGP6FPP42VPsPh_FoJ8A-1; Fri, 13 May 2022 11:19:21 -0400 X-MC-Unique: QlzGP6FPP42VPsPh_FoJ8A-1 Received: by mail-wm1-f69.google.com with SMTP id r186-20020a1c44c3000000b00393f52ed5ceso6085640wma.7 for ; Fri, 13 May 2022 08:19:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=NTq9ilDcl4Oroc8d2FZa/UfstF2HBb6rd+7kKNOuUmo=; b=fBk9Z9D3Q+/SGIME6cvqdJpS4xa8ndZi9j6zBgRaRUistZJe73xL9YIaZ+mav84bKN qnUPsAdYellocefY1EKQ0cpdL8LhNfracKXaJhBnAik93Op377q4cSl44ibU95KxAg/n iCq/7XoveLPAkKZajL20kd/ENYZ3lnX2d0J6yyrMhCCR1bHpMKriBtZJUGE3fm89BKzu oYQVQHVkrOwiGZaTtAwFrZjNdCFokWQGkqtvw7BH7ZwHp4NPpMhHMfGJx7Lo9dCggUm9 JH4yC2ndLsnwEZ4mv5G0rWk0TFAnqQqp4MN5+l1/nKnIfwBiNBaIU8JrCAU47V2HwojP noTg== X-Gm-Message-State: AOAM530YLaikMgRVnlyajfidLY+W1MdquNNnRDTuewewozvVR8XltLFq 8ldn4Smr8eWAwg25ohxy/f7Of5xB+bvCzNsqgDJ8wjRmoSzEqpLX5sx1HdZcGcbZhtuQTfoNnw6 GYxsKr120jlI= X-Received: by 2002:a05:600c:4994:b0:394:dcb:d66d with SMTP id h20-20020a05600c499400b003940dcbd66dmr15479891wmp.178.1652455160222; Fri, 13 May 2022 08:19:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyJd+uqBnpkb5/EK2zAx8aimGhL05ytMmLYzIQgtxlp5FRqWBVZ0uL7X0KwWiNTjox0x0aKdg== X-Received: by 2002:a05:600c:4994:b0:394:dcb:d66d with SMTP id h20-20020a05600c499400b003940dcbd66dmr15479859wmp.178.1652455159912; Fri, 13 May 2022 08:19:19 -0700 (PDT) Received: from ?IPv6:2a0c:5a80:1306:2f00:be0e:91f7:c0a3:32f0? ([2a0c:5a80:1306:2f00:be0e:91f7:c0a3:32f0]) by smtp.gmail.com with ESMTPSA id y2-20020a05600c364200b00394699f803dsm5604106wmq.46.2022.05.13.08.19.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 May 2022 08:19:19 -0700 (PDT) Message-ID: <167d30f439d171912b1ef584f20219e67a009de8.camel@redhat.com> Subject: Re: [PATCH 6/6] mm/page_alloc: Remotely drain per-cpu lists From: Nicolas Saenz Julienne To: Mel Gorman , Andrew Morton Cc: Marcelo Tosatti , Vlastimil Babka , Michal Hocko , LKML , Linux-MM Date: Fri, 13 May 2022 17:19:18 +0200 In-Reply-To: <20220513150402.GJ3441@techsingularity.net> References: <20220512085043.5234-1-mgorman@techsingularity.net> <20220512085043.5234-7-mgorman@techsingularity.net> <20220512123743.5be26b3ad4413f20d5f46564@linux-foundation.org> <20220513150402.GJ3441@techsingularity.net> User-Agent: Evolution 3.44.1 (3.44.1-1.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 82FA11400A5 X-Stat-Signature: f3qn8q8391ek663x1f36fqwkn8tt1ik5 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Yp84L6YD; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf09.hostedemail.com: domain of nsaenzju@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=nsaenzju@redhat.com X-Rspam-User: X-HE-Tag: 1652455154-553789 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 Fri, 2022-05-13 at 16:04 +0100, Mel Gorman wrote: > On Thu, May 12, 2022 at 12:37:43PM -0700, Andrew Morton wrote: > > On Thu, 12 May 2022 09:50:43 +0100 Mel Gorman wrote: > >=20 > > > From: Nicolas Saenz Julienne > > >=20 > > > Some setups, notably NOHZ_FULL CPUs, are too busy to handle the per-c= pu > > > drain work queued by __drain_all_pages(). So introduce a new mechanis= m to > > > remotely drain the per-cpu lists. It is made possible by remotely loc= king > > > 'struct per_cpu_pages' new per-cpu spinlocks. A benefit of this new s= cheme > > > is that drain operations are now migration safe. > > >=20 > > > There was no observed performance degradation vs. the previous scheme= . > > > Both netperf and hackbench were run in parallel to triggering the > > > __drain_all_pages(NULL, true) code path around ~100 times per second. > > > The new scheme performs a bit better (~5%), although the important po= int > > > here is there are no performance regressions vs. the previous mechani= sm. > > > Per-cpu lists draining happens only in slow paths. > > >=20 > > > Minchan Kim tested this independently and reported; > > >=20 > > > =09My workload is not NOHZ CPUs but run apps under heavy memory > > > =09pressure so they goes to direct reclaim and be stuck on > > > =09drain_all_pages until work on workqueue run. > > >=20 > > > =09unit: nanosecond > > > =09max(dur) avg(dur) count(dur) > > > =09166713013 487511.77786438033 1283 > > >=20 > > > =09From traces, system encountered the drain_all_pages 1283 times and > > > =09worst case was 166ms and avg was 487us. > > >=20 > > > =09The other problem was alloc_contig_range in CMA. The PCP draining > > > =09takes several hundred millisecond sometimes though there is no > > > =09memory pressure or a few of pages to be migrated out but CPU were > > > =09fully booked. > > >=20 > > > =09Your patch perfectly removed those wasted time. > >=20 > > I'm not getting a sense here of the overall effect upon userspace > > performance. As Thomas said last year in > > https://lkml.kernel.org/r/87v92sgt3n.ffs@tglx > >=20 > > : The changelogs and the cover letter have a distinct void vs. that whi= ch > > : means this is just another example of 'scratch my itch' changes w/o > > : proper justification. > >=20 > > Is there more to all of this than itchiness and if so, well, you know > > the rest ;) > >=20 >=20 > I think Minchan's example is clear-cut. The draining operation can take > an arbitrary amount of time waiting for the workqueue to run on each CPU > and can cause severe delays under reclaim or CMA and the patch fixes > it. Maybe most users won't even notice but I bet phone users do if a > camera app takes too long to open. >=20 > The first paragraphs was written by Nicolas and I did not want to modify > it heavily and still put his Signed-off-by on it. Maybe it could have > been clearer though because "too busy" is vague when the actual intent > is to avoid interfering with RT tasks. Does this sound better to you? >=20 > =09Some setups, notably NOHZ_FULL CPUs, may be running realtime or > =09latency-sensitive applications that cannot tolerate interference > =09due to per-cpu drain work queued by __drain_all_pages(). Introduce > =09a new mechanism to remotely drain the per-cpu lists. It is made > =09possible by remotely locking 'struct per_cpu_pages' new per-cpu > =09spinlocks. This has two advantages, the time to drain is more > =09predictable and other unrelated tasks are not interrupted. >=20 > You raise a very valid point with Thomas' mail and it is a concern that > the local_lock is no longer strictly local. We still need preemption to > be disabled between the percpu lookup and the lock acquisition but that > can be done with get_cpu_var() to make the scope clear. This isn't going to work in RT :( get_cpu_var() disables preemption hampering RT spinlock use. There is more = to it in Documentation/locking/locktypes.rst. Regards, --=20 Nicol=C3=A1s S=C3=A1enz