From patchwork Wed Nov 3 17:05:09 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Saenz Julienne X-Patchwork-Id: 12601227 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 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 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, only 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 task 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 without breaking their functional guarantees (latency, bandwidth, etc...). This new locking scheme, based on per-cpu spinlocks, is the simpler and more maintainable approach so far[1], although also has some drawbacks: it comes 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 believe 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 discussed 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 removes dead code. The series is based on today's linux-next. 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 extra config option makes is painful to maintain (v1): https://lore.kernel.org/linux-mm/20210921161323.607817-5-nsaenzju@redhat.com/ - RCU based approach, complex, yet a bit less taxing performance wise (RFC): https://lore.kernel.org/linux-mm/20211008161922.942459-4-nsaenzju@redhat.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(-)