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 A6F9CC433F5 for ; Tue, 30 Nov 2021 18:09:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 010796B0072; Tue, 30 Nov 2021 13:09:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F016E6B0073; Tue, 30 Nov 2021 13:09:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF10A6B0075; Tue, 30 Nov 2021 13:09:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0246.hostedemail.com [216.40.44.246]) by kanga.kvack.org (Postfix) with ESMTP id D130B6B0072 for ; Tue, 30 Nov 2021 13:09:38 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 9AA4A180AD804 for ; Tue, 30 Nov 2021 18:09:28 +0000 (UTC) X-FDA: 78866383932.27.EEE2E27 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id DAE35B0000AD for ; Tue, 30 Nov 2021 18:09:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638295767; 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=/dCW7AjvcsfnQ6JeVlt/Lp1KjBKaBEwl0X0gDNVXxzs=; b=cYDfDa/kRqJRn50vNwhY3UMSRS1hZTGB+Xii6xncv+QyqNLbGDgOdpt2iwY45/NsR+8YNz FnYrX6yWqDWrcIvwXXlQswBxE6rrbF+Jq/6cLPyvTY3m/TEFMaj7V1WW41RPuEaYqVP0BO 911DZizjNkPpHGAXtz3u3F33lhzLp2g= 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-423-c_thN0KFPSeJA7dST1MoOw-1; Tue, 30 Nov 2021 13:09:25 -0500 X-MC-Unique: c_thN0KFPSeJA7dST1MoOw-1 Received: by mail-wm1-f70.google.com with SMTP id 145-20020a1c0197000000b0032efc3eb9bcso14217777wmb.0 for ; Tue, 30 Nov 2021 10:09:25 -0800 (PST) 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:user-agent:mime-version:content-transfer-encoding; bh=/dCW7AjvcsfnQ6JeVlt/Lp1KjBKaBEwl0X0gDNVXxzs=; b=OXSpYJi29IybyJTGsvaZs86QY1COyQmat5krnHuy9+MH3X9tskFLbmwo3XiwA0lHic ReMBYXcGBRI/kj3Rwc8q95MTAmj6KcYwxyMrjoxt8RC5+SvjwhecW1Ohbm+zZcjAoikg VTrc7Tl3W7hU72NVDNglkmpYkExMXtkRVmsMtnMQA/SfxQFPCwPZa+PnP7WEXfgoOtXV PwI/JeWXOVDyPzBPfsacSGbRWAkjPGiteTyvgxF03egG7/g5NsaMqYPO7bu4xrL2boAN 8E72EZwpTLCzWIIG70iBoxsVK+yWTgNjxOKRZHPETPDimQFS3XfIkqilDWvuZtSkgV6M L2gA== X-Gm-Message-State: AOAM5335WB3FbRfdQmtqOmvo884hTmQHxTCu1g3bCjjTedt8ByYJ/H6l Iow/SOkcwkkv0xAi1hPfgWWzJeNceMwExOOoEoFZkPA7KEuVySbq14Q81cvavpMLtHo3jm7bnm/ 9cIRrWM8QP70= X-Received: by 2002:adf:a190:: with SMTP id u16mr541686wru.483.1638295764515; Tue, 30 Nov 2021 10:09:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJyk/oWb3w92b8sLB1B0V/nf4I6+6tqcRtn+THDoTOs5Hd0j+FZWS7V/drDTU5g4AY19i8KuWg== X-Received: by 2002:adf:a190:: with SMTP id u16mr541639wru.483.1638295764253; Tue, 30 Nov 2021 10:09:24 -0800 (PST) Received: from ?IPv6:2a0c:5a80:3c10:3400:3c70:6643:6e71:7eae? ([2a0c:5a80:3c10:3400:3c70:6643:6e71:7eae]) by smtp.gmail.com with ESMTPSA id h7sm16358802wrt.64.2021.11.30.10.09.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Nov 2021 10:09:24 -0800 (PST) Message-ID: <43462fe11258395f4e885c3d594a3ed1b604b858.camel@redhat.com> Subject: Re: [PATCH v2 0/3] mm/page_alloc: Remote per-cpu page list drain support From: Nicolas Saenz Julienne To: Vlastimil Babka , 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, cl@linux.com, ppandit@redhat.com Date: Tue, 30 Nov 2021 19:09:23 +0100 In-Reply-To: <7549db15-5149-160f-86e3-55136fe482ce@suse.cz> References: <20211103170512.2745765-1-nsaenzju@redhat.com> <7549db15-5149-160f-86e3-55136fe482ce@suse.cz> User-Agent: Evolution 3.42.1 (3.42.1-1.fc35) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: jpac3ce4xhpjogx5u6ww7cn8irjqizha X-Rspamd-Queue-Id: DAE35B0000AD X-Rspamd-Server: rspam07 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="cYDfDa/k"; spf=none (imf24.hostedemail.com: domain of nsaenzju@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=nsaenzju@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1638295762-577649 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: Hi Vlastimil, sorry for the late reply and thanks for your feedback. :) On Tue, 2021-11-23 at 15:58 +0100, Vlastimil Babka wrote: > > [1] Other approaches can be found here: > >=20 > > - 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/ > >=20 > > - RCU based approach, complex, yet a bit less taxing performance wi= se > > (RFC): > > https://lore.kernel.org/linux-mm/20211008161922.942459-4-nsaenzju= @redhat.com/ >=20 > Hm I wonder if there might still be another alternative possible. IIRC = I did > propose at some point a local drain on the NOHZ cpu before returning to > userspace, and then avoiding that cpu in remote drains, but tglx didn't= like > the idea of making entering the NOHZ full mode more expensive [1]. >=20 > But what if we instead set pcp->high =3D 0 for these cpus so they would= avoid > populating the pcplists in the first place? Then there wouldn't have to= be a > drain at all. On the other hand page allocator operations would not ben= efit > from zone lock batching on those cpus. But perhaps that would be accept= able > tradeoff, as a nohz cpu is expected to run in userspace most of the tim= e, > and page allocator operations are rare except maybe some initial page > faults? (I assume those kind of workloads pre-populate and/or mlock the= ir > address space anyway). I've looked a bit into this and it seems straightforward. Our workloads pre-populate everything, and a slight statup performance hit is not that = tragic (I'll measure it nonetheless). The per-cpu nohz_full state at some point = will be dynamic, but the feature seems simple to disable/enable. I'll have to = teach __drain_all_pages(zone, force_all_cpus=3Dtrue) to bypass this special cas= e but that's all. I might have a go at this. Thanks! --=20 Nicol=C3=A1s S=C3=A1enz