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 A97FBC433EF for ; Tue, 26 Apr 2022 02:49:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F00796B0073; Mon, 25 Apr 2022 22:49:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E86AB6B0074; Mon, 25 Apr 2022 22:49:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D017C6B0075; Mon, 25 Apr 2022 22:49:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id BB4726B0073 for ; Mon, 25 Apr 2022 22:49:58 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 8BC02804B3 for ; Tue, 26 Apr 2022 02:49:58 +0000 (UTC) X-FDA: 79397500476.27.B1C24DB Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by imf05.hostedemail.com (Postfix) with ESMTP id 1F092100052 for ; Tue, 26 Apr 2022 02:49:51 +0000 (UTC) Received: by mail-pf1-f174.google.com with SMTP id i24so16637579pfa.7 for ; Mon, 25 Apr 2022 19:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HGAx5TP6E+vFvjaPxhYu9IBA2KbCco9Opl8nE6JlHZY=; b=TveONqNNTAMKRK3L5GedChuTwratL2NBA5QmxDHEPJFdUx05XPxL7uzHbRQY1k0VP+ QGH4vuhM4l6pRcU6c0G34VDTbDUmPHxvv/2QcICPqvaF2aOfkmv5iDhxDdpNFG2PzDzj pVqxylha350zoMW4sh2LSwIKCi5PJEAchJAFFeCM5Acuy2sM+GxRmKsNJmNPFojYgmX1 Tq/Bm1NlqR15AOfXiapXAZ9YImmAVAuDwPA54qd2TKhq011xasmBS0UWXvJ2iYsjQXZ0 elsIdKj+CrA5a+ZyziFasVwk+CJcf0z/2JppV5lGCAXx4HLyAoOxvDhbhfY9cGW42Y/S qEvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HGAx5TP6E+vFvjaPxhYu9IBA2KbCco9Opl8nE6JlHZY=; b=obXWT49ecyeqM+G2L+CcrN3CJpceREDfNY7bpV3D5aE/RodVQzHOH+EpzH8A+kXNa/ P55EcfacqwURi4uhKuLOyAa3ci3IImVjyrnMHjbiQAxlaOJp9D3Z8n2buZtIUZ1kScA0 d1lFZaeHJR47Uwit/IgykIT8D8lU/qj4ArYiWHKqgFVTuVoYUt2DtqkI3cahDCkiD6t4 h7pO79HVxHqikF2I1jLtJrWpLK4K/gaos5hfcDK0ZqccL3JLr2GAuB1vTwRvuzmOW9fy asoxeEyVpD6CEBYvGPNdl7VSagnPU13K0PSCpou566jHjNLW01sAQABqxZoezSIVZBUi /MdA== X-Gm-Message-State: AOAM532IO8yus9Za/lN1XIYUetaGWQNSqQYOLBQVNxpwGNZCSlkcJXn1 cytCdG8TcGzCELNlbx7UktGg0YguVJcBN8qeKeSbDw== X-Google-Smtp-Source: ABdhPJxuQRhkzahWKLzhvbzo8kOU6fZ3ZFG6NDOaZbwPYeIG96+3TCV/J6Ekta0ZZ7sN6E0Awm1X0rw0AMHSXRG8k3A= X-Received: by 2002:a63:89c7:0:b0:3ab:1f12:f807 with SMTP id v190-20020a6389c7000000b003ab1f12f807mr9017915pgd.180.1650941396751; Mon, 25 Apr 2022 19:49:56 -0700 (PDT) MIME-Version: 1.0 References: <20220420095906.27349-1-mgorman@techsingularity.net> In-Reply-To: <20220420095906.27349-1-mgorman@techsingularity.net> From: Suren Baghdasaryan Date: Mon, 25 Apr 2022 19:49:46 -0700 Message-ID: Subject: Re: [RFC PATCH 0/6] Drain remote per-cpu directly To: Mel Gorman Cc: Nicolas Saenz Julienne , Marcelo Tosatti , Vlastimil Babka , Michal Hocko , LKML , Linux-MM Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: eu68jrhfzwkrpqbb5gdnbanfffc8hb45 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1F092100052 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=TveONqNN; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.210.174 as permitted sender) smtp.mailfrom=surenb@google.com X-HE-Tag: 1650941391-955827 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 20, 2022 at 2:59 AM Mel Gorman wrote: > > 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. > > Currently an IRQ-safe local_lock protects the page allocator per-cpu lists. > The local_lock on its own prevents migration and the IRQ disabling protects > 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. > > This series adjusts the locking. A spin-lock 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. > > This series is a partial series. Follow-on work would allow the > local_irq_save to be converted to a local_irq to avoid IRQs being > disabled/enabled in most cases. 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. > > Patch 1 is a cosmetic patch to clarify when page->lru is storing buddy pages > and when it is storing per-cpu pages. > > Patch 2 shrinks per_cpu_pages to make room for a spin lock. Strictly speaking > this is not necessary but it avoids per_cpu_pages consuming another > cache line. > > Patch 3 is a preparation patch to avoid code duplication. > > Patch 4 is a simple micro-optimisation that improves code flow necessary for > a later patch to avoid code duplication. > > Patch 5 uses a spin_lock to protect the per_cpu_pages contents while still > relying on local_lock to prevent migration, stabilise the pcp > lookup and prevent IRQ reentrancy. > > Patch 6 remote drains per-cpu pages directly instead of using a workqueue. This quite possibly solves the issue I was trying to fix in https://lore.kernel.org/all/20220225012819.1807147-1-surenb@google.com. I will give it a try and see how it looks. Thanks! > > include/linux/mm_types.h | 5 + > include/linux/mmzone.h | 12 +- > mm/page_alloc.c | 333 ++++++++++++++++++++++++--------------- > 3 files changed, 222 insertions(+), 128 deletions(-) > > -- > 2.34.1 > >