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 3E39FC433EF for ; Wed, 18 May 2022 18:01:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE9C86B0074; Wed, 18 May 2022 14:01:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C99576B0075; Wed, 18 May 2022 14:01:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B39ED8D0001; Wed, 18 May 2022 14:01:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A4DDB6B0074 for ; Wed, 18 May 2022 14:01:13 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6E90460742 for ; Wed, 18 May 2022 18:01:13 +0000 (UTC) X-FDA: 79479630426.08.16C52C8 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 93E2418010A for ; Wed, 18 May 2022 18:01:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652896871; 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=z8xlrowAUvM1/2ybSeOaJOkkrtVJbfEDH0nQAodlR3g=; b=Zxz9qyUfmsXIm6YpvDA+OQHtwe5j/gn0Jnf61eltLGIPJvJ6k3yp2EAy3h6in/0Ty1BuDQ jfj3PkayODN4PgHAusIg20TVBsGVDsQ7snbBmftyR5o0LfzeLUz+K05+T3dOVg1OEQfMjl PQWvTYZONdU03S7aFbqnLuDHJPAZ/3A= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-390-4tOdcrmCOiWP9uShzKcoqA-1; Wed, 18 May 2022 14:01:10 -0400 X-MC-Unique: 4tOdcrmCOiWP9uShzKcoqA-1 Received: by mail-wm1-f70.google.com with SMTP id c187-20020a1c35c4000000b003970013833aso1176209wma.1 for ; Wed, 18 May 2022 11:01:10 -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=z8xlrowAUvM1/2ybSeOaJOkkrtVJbfEDH0nQAodlR3g=; b=ifDFpwfYsBZPhm1MC3l7MDhpyVp7KWQ21nqflX2Vehu8NU5aUvSwUqiCjQ+SmgxBsC Vh2eA5hdfpjkm1jN9KK19TbkuHzOXdWLcbZNSa22MSJYeOKqvaQSkVpMlpBDUNjGwjlS UazhoSrlUlYLtvTs5uMV1VGXH4JGYnuIeMp2vDvAIHHEVajb61zHCJheOgs1ywtPSBid yks3eawMfZ1AVnMrdvEioEeVBCdYROjZg7v68hR/6fwY0CLT50f+EQ8zTc/Sg7yONyD4 SHc39d39vfPNAWFHo/10Vo8huwiYgioClkPjn4g2Cwomt2grg2++fXe+811QQgLHJTFN M3gQ== X-Gm-Message-State: AOAM5329BZoQ/49je+U98c7qlQk++LNrvMEnqJEP14/2Mwjq+YEiYOn0 PjLX6vYYCW8PFuslUP2BBvRNDN+ggEJy1T54YsAWNdCYKwhoSzln47BP0pjCyMBI8OSqpVngpij x5LJGO79q23s= X-Received: by 2002:a7b:ce02:0:b0:381:2007:f75c with SMTP id m2-20020a7bce02000000b003812007f75cmr1050655wmc.6.1652896869391; Wed, 18 May 2022 11:01:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxBcYFHJwrznm9sfk4CRqqfgijdDfW6hPYDdn37Qxw4KOcOCf+ZFixqXha94HyPD+3N3LMb4g== X-Received: by 2002:a7b:ce02:0:b0:381:2007:f75c with SMTP id m2-20020a7bce02000000b003812007f75cmr1050631wmc.6.1652896869182; Wed, 18 May 2022 11:01:09 -0700 (PDT) Received: from ?IPv6:2a0c:5a80:1d02:ba00:f4f8:7394:c8:7ddf? ([2a0c:5a80:1d02:ba00:f4f8:7394:c8:7ddf]) by smtp.gmail.com with ESMTPSA id j10-20020adfa78a000000b0020c5253d8fcsm3034662wrc.72.2022.05.18.11.01.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 11:01:08 -0700 (PDT) Message-ID: <09fbcf0884ef5e03812566b9576979253e506ce9.camel@redhat.com> Subject: Re: [PATCH 0/6] Drain remote per-cpu directly v3 From: Nicolas Saenz Julienne To: Mel Gorman , Andrew Morton Cc: Marcelo Tosatti , Vlastimil Babka , Michal Hocko , LKML , Linux-MM Date: Wed, 18 May 2022 20:01:07 +0200 In-Reply-To: <20220512085043.5234-1-mgorman@techsingularity.net> References: <20220512085043.5234-1-mgorman@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 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Zxz9qyUf; spf=none (imf24.hostedemail.com: domain of nsaenzju@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=nsaenzju@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 93E2418010A X-Stat-Signature: caxmoj1eam1ocpr5iadbm5bhds5hu4ns X-HE-Tag: 1652896861-803120 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, 2022-05-12 at 09:50 +0100, Mel Gorman wrote: > Changelog since v2 > o More conversions from page->lru to page->[pcp_list|buddy_list] > o Additional test results in changelogs >=20 > Changelog since v1 > o Fix unsafe RT locking scheme > o Use spin_trylock on UP PREEMPT_RT >=20 > This series has the same intent as Nicolas' series "mm/page_alloc: Remote > per-cpu lists drain support" -- avoid interference of a high priority > task due to a workqueue item draining per-cpu page lists. While many > workloads can tolerate a brief interruption, it may be cause a real-time > task runnning on a NOHZ_FULL CPU to miss a deadline and at minimum, > the draining in non-deterministic. >=20 > Currently an IRQ-safe local_lock protects the page allocator per-cpu list= s. > The local_lock on its own prevents migration and the IRQ disabling protec= ts > from corruption due to an interrupt arriving while a page allocation is > in progress. The locking is inherently unsafe for remote access unless > the CPU is hot-removed. >=20 > This series adjusts the locking. A spinlock is added to struct > per_cpu_pages to protect the list contents while local_lock_irq continues > to prevent migration and IRQ reentry. This allows a remote CPU to safely > drain a remote per-cpu list. >=20 > This series is a partial series. Follow-on work should allow the > local_irq_save to be converted to a local_irq to avoid IRQs being > disabled/enabled in most cases. Consequently, there are some TODO comment= s > highlighting the places that would change if local_irq was used. However, > there are enough corner cases that it deserves a series on its own > separated by one kernel release and the priority right now is to avoid > interference of high priority tasks. FWIW tested this against our RT+nohz_full workloads. I can have another go = if the locking scheme changes. Tested-by: Nicolas Saenz Julienne Thanks, --=20 Nicol=C3=A1s S=C3=A1enz