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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8D806C433F5 for ; Wed, 3 Nov 2021 17:06:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3856F610EA for ; Wed, 3 Nov 2021 17:06:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3856F610EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C52CE6B0075; Wed, 3 Nov 2021 13:06:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BB39F6B0078; Wed, 3 Nov 2021 13:06:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7C39940007; Wed, 3 Nov 2021 13:06:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by kanga.kvack.org (Postfix) with ESMTP id 977676B0075 for ; Wed, 3 Nov 2021 13:06:45 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4E7F35CB81 for ; Wed, 3 Nov 2021 17:06:45 +0000 (UTC) X-FDA: 78768248328.26.DE8B700 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 74118F00009B for ; Wed, 3 Nov 2021 17:06:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635959204; 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; bh=+f9atatdU2nnvM9ItKdkQH/ZAOJGs+MlbwdXfCEnlhQ=; b=dpCXMElzt0C4JwN4FBsA0xRe2SxQSi/4frunAmJ602Z0Rmw9a2fPitN3XgXB+CfPwzihd1 stj/XphL7PXoupHtYK92ssRZTQxG4mK54Xody+v/jKcqkOR614qGxC6uHnFT1Bz6jbrK6N ZKWdzisj4PJii8jj0TSdd/2eKKmLQiU= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-9-I9mg-RO8NWa7JV-oqlcsTw-1; Wed, 03 Nov 2021 13:05:19 -0400 X-MC-Unique: I9mg-RO8NWa7JV-oqlcsTw-1 Received: by mail-wr1-f69.google.com with SMTP id q7-20020adff507000000b0017d160d35a8so568349wro.4 for ; Wed, 03 Nov 2021 10:05:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=+f9atatdU2nnvM9ItKdkQH/ZAOJGs+MlbwdXfCEnlhQ=; b=aY85R21WtwirhvsvL0ctILIahzQcX80aO3Lb6dgdiIa6EYEEGesh6FOniMZBqRsuSo 1gpOwrI4svDKA5Qgy7njfUpBsT4kdTpQY/R+7TBKIsSsVvWPEQMyXjRZjYvjclboBkGX 9+6ukBKExpTHfzMn7RSbla2nfbfAixVfL6CS6oZ+qE6HvgVcAkQm+vB23K9rXSNCPueg TZ8tnRmuYzGHSRLPx8CFNgWJmCwMByI9lDt53meFuHOgDirhtzeaQzQIj2zPAXOBl7OO mXbQtH+3O66sYXa5DyZthC0UVzAT5WGC1twHbJ1Z03m6lHaACaXILW9iAPWtD1g/TX2l A1Rw== X-Gm-Message-State: AOAM5308JsKp23UZy/2X1bZtc3dM+IXWhXVyyN6NXrYFgn71crzy+IA0 8ZoPPs1O3dzsboLVv+32ZFLSpj/MUCXq4ORXtwL2ArPxCeg0OilkVY+SPlhBc837Yk3f1jYmNpH FDqUbYTnN9Jw= X-Received: by 2002:a05:600c:22c7:: with SMTP id 7mr16394398wmg.58.1635959117674; Wed, 03 Nov 2021 10:05:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLQHIxWBGipmQG2N4mWPaZQrmHOYgh8w0bbIdQ9xPNXlaB1oCioABznXluNH8LAtEML5rCZQ== X-Received: by 2002:a05:600c:22c7:: with SMTP id 7mr16394343wmg.58.1635959117291; Wed, 03 Nov 2021 10:05:17 -0700 (PDT) Received: from vian.redhat.com ([2a0c:5a80:3c10:3400:3c70:6643:6e71:7eae]) by smtp.gmail.com with ESMTPSA id h22sm2900610wmq.14.2021.11.03.10.05.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Nov 2021 10:05:16 -0700 (PDT) From: Nicolas Saenz Julienne To: akpm@linux-foundation.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, frederic@kernel.org, tglx@linutronix.de, peterz@infradead.org, mtosatti@redhat.com, nilal@redhat.com, mgorman@suse.de, linux-rt-users@vger.kernel.org, vbabka@suse.cz, cl@linux.com, ppandit@redhat.com, Nicolas Saenz Julienne Subject: [PATCH v2 0/3] mm/page_alloc: Remote per-cpu page list drain support Date: Wed, 3 Nov 2021 18:05:09 +0100 Message-Id: <20211103170512.2745765-1-nsaenzju@redhat.com> X-Mailer: git-send-email 2.33.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="US-ASCII" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 74118F00009B X-Stat-Signature: rxi8tr9zn3dkrwx5rzyj49cqjycaip91 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dpCXMElz; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of nsaenzju@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=nsaenzju@redhat.com X-HE-Tag: 1635959197-325012 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: This series introduces a new locking scheme around mm/page_alloc.c's per-= cpu page lists which will allow for remote CPUs to drain them. Currently, onl= y a local CPU is permitted to change its per-cpu lists, and it's expected to = do so, on-demand, whenever a process demands it (by means of queueing an drain t= ask on the local CPU). Most systems will handle this promptly, but it'll cause problems for NOHZ_FULL CPUs that can't take any sort of interruption with= out breaking their functional guarantees (latency, bandwidth, etc...). This new locking scheme, based on per-cpu spinlocks, is the simpler and m= ore maintainable approach so far[1], although also has some drawbacks: it com= es with a small performance. Depending on the page allocation code path micro-benchmark we can expect 0% to 0.6% degradation on x86_64, and 0% to= 2% on arm64[2]. Assuming there is nothing too horrible in the patches themselves I believ= e it all comes down to whether we prefer to take the small performance hit vs = the maintenance burden of a more complex solution[1]. I don't have enough experience with performance tuning, nor with maintenance to have an authoritative opinion here, so I'll defer to whatever is hopefully discus= sed here. Also, I'll be happy to run any extra tests that I might have missed= . Patch #1 could be taken regardless of the rest of the series as it remove= s dead code. The series is based on today's linux-next.=20 Changes since v2: - Provide performance numbers - Unanimously use per-cpu spinlocks [1] Other approaches can be found here: - Static branch conditional on nohz_full, no performance loss, the extr= a config option makes is painful to maintain (v1): https://lore.kernel.org/linux-mm/20210921161323.607817-5-nsaenzju@red= hat.com/ - RCU based approach, complex, yet a bit less taxing performance wise (RFC): https://lore.kernel.org/linux-mm/20211008161922.942459-4-nsaenzju@red= hat.com/ [2] See individual patches for in-depth results --- Nicolas Saenz Julienne (3): mm/page_alloc: Don't pass pfn to free_unref_page_commit() mm/page_alloc: Convert per-cpu lists' local locks to per-cpu spin locks mm/page_alloc: Remotely drain per-cpu lists include/linux/mmzone.h | 1 + mm/page_alloc.c | 151 ++++++++++++++--------------------------- 2 files changed, 52 insertions(+), 100 deletions(-) --=20 2.33.1