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 28268C54E71 for ; Tue, 19 Mar 2024 21:08:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7458F6B007B; Tue, 19 Mar 2024 17:08:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F6626B0082; Tue, 19 Mar 2024 17:08:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BDAB6B0083; Tue, 19 Mar 2024 17:08:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 497436B007B for ; Tue, 19 Mar 2024 17:08:36 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 10B03A074A for ; Tue, 19 Mar 2024 21:08:36 +0000 (UTC) X-FDA: 81915027432.17.06085ED Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf22.hostedemail.com (Postfix) with ESMTP id E2FCFC0018 for ; Tue, 19 Mar 2024 21:08:32 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=tKfcKMcc; dmarc=none; spf=pass (imf22.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710882513; h=from:from:sender: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:dkim-signature; bh=7m4Dg/wcUz9yS7JHUwXjaYbKATxxk+aoNRsQy09wwGc=; b=PxzikC3QM53UK4LJudqypW85+qmMRreJFbNr/5wNvo4jXnTD0NGY9+NOF+7PzUEiIkZD3y lpJ+UatAcdqNiZOpf5cVoEkNJZG/ufj6ySxAWbmAzE/BRQlFgz067iDwuoIy5n5EytGstI s3WbXxUD2ZUhuCBPSXelUItgRGjW/RY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=tKfcKMcc; dmarc=none; spf=pass (imf22.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710882513; a=rsa-sha256; cv=none; b=sC6+axq6cD6xwh1SvLgYtyHPnhoBMEWl0P3Pn8Bv3WHcSZ30Foqf6g9hnivkuxmFqVHkAM hawjKcr0QMOeTeqwNty4ChIeDymDPsEhNAR9CDtUDLaaK9ezoRNe6KrzOAYFOemBvQ3K4l JvQ/QFg3ASId7VBGV+uVdUH3nQb80Ts= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 6FF94CE0F09; Tue, 19 Mar 2024 21:08:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7CB1DC433F1; Tue, 19 Mar 2024 21:08:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1710882508; bh=H7SUSYHf+1zLRNJfv0IhsNXSFgnWEIQMJ2LUJnZapm8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tKfcKMcc94XXmX9wJPOxjSeyzLwiwzrnQV90qXWaJZ9GIIj2yuOuQNOFflLoRT0aF nRTue2gDAoPqFto5szElQ1QQHnaA9kHIi0CKnwTSMbsXbVtewT9LY91AxP+/+qk0WR y7ukD3jYIVVGDFoeGG+/A02EzHAK6UN6bzCGHFOY= Date: Tue, 19 Mar 2024 14:08:27 -0700 From: Andrew Morton To: Lucas Stach Cc: linux-mm@kvack.org, kernel@pengutronix.de, patchwork-lst@pengutronix.de, Mel Gorman Subject: Re: [PATCH] mm: page_alloc: control latency caused by zone PCP draining Message-Id: <20240319140827.cd845c84a13a8d817ffbc96f@linux-foundation.org> In-Reply-To: <20240318200736.2835502-1-l.stach@pengutronix.de> References: <20240318200736.2835502-1-l.stach@pengutronix.de> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E2FCFC0018 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 8rfufmh3oankzomb83tkbbdnhmks6yn3 X-HE-Tag: 1710882512-300833 X-HE-Meta: U2FsdGVkX1+yPFS/hq/FJLp8GlTizeaN1xEWc+tmVIG8fsSQN9VYOFQmi59WsIkCr7M+f0udxwD0aU6/eIdn7lonsqa3v0K0rNL+IW3kuQhxKZHQT133Gotq+6SfGO43zH65E36mzCEF7a5uQPHjh3YG8vMSWaLcTPxQXd1DmyV6TSVX781teX8/nWsnd26KxeBvyWbNZNGeM/oYGcMduCZa01bE7nkpXb6bgz7AwG/et38XSL5PZnTncsdGyTakeIQqIBvz1/4h19jD2xG6QGF+rJier9AJABqPHKnZE9iEa30c3s8wHlvAr4wY0lIQKQN1J3BObeEDa91/ZzMZw+Vvj3ZQpwCR5pTgWbpIESrDcc1Fpfm4U7LMestb3YXOSXv8y2Ku/pDk4qL0QWJJLNAkbY4xZO5llIn3L5OoW0OR+SPkQiiCcm0Il9uuva0Fp8ky9FfnNySS4CQkK2YdWesjdyTzGjeGMLMBjOzkaFhSWo9XvyU3qC5FQwa+S7d8SucfTagX+/NaEcxTIENRvbhJ8faJns+nig428PGycacHO1tdy4hH9SpKRMwJuTrSefvzDiBktz9pWPEle3DU1TnC+5jxJCtXmwdOb/W6EUcxa/clWd80ASXmrP2BdHwVwJbxgQ/MPpL23aySqXS54c/K2+SrNwifTaAUiFUFZQmHe30Y8GWfgI6hz2MFvTkK03rw+9bHcGN3HXubHxuXyCPU8l8RSXvkJuW6vR9QNxeoYwFD5yApbf55TZJAiaO9B1nLids1y3cgS/G06WldBU7VhgJR7zbWP7VokG1N2hNdIY58jSZs+zw9CeSmm8gZaQONZf6ywskF8o6zzZTWSQxe8g/StFWsAYhukLFWsGe4hC2W4RtzgIoqdgGKEVlxt+i7rJqRyP0x1LPXBnw4kc8bZHaEE5ahr98z7SaRcD6fjaJuxiQB87wNj5q7/RPkxkF4oGS2+eDxqGJPB2Y TfPmkgpo O4SJzW1VnHYqxiLtbzKqUIiOBIDNZfpMgAKz+qw+EBxmSSojaVw2XV+OUhaF6a80btcG59hz4E2rJhcKf67ulH0tozmlnM8vpDqGlM1wGdK3YuQYht9v6KUXvAIh8MptTlGvoozQjAlEGL5ObRhXT9J50SEOJ7147LxIGGD+urrYJm5FjIEZbxN5fcOMsEAUHoCz6wcxaSS//tjhOjJ2iqJ30IJ6JmRN/2sHGVg6vh5WnUle4wV4PEj6smKdHLUrUBmP8+Ta1AI7Z/a2Qfp0Ti+yHPw== 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: List-Subscribe: List-Unsubscribe: On Mon, 18 Mar 2024 21:07:36 +0100 Lucas Stach wrote: > When the complete PCP is drained a much larger number of pages > than the usual batch size might be freed at once, How much larger? Please include the numbers here. > causing large > IRQ and preemption latency spikes, as they are all freed while > holding the pcp and zone spinlocks. How large are these spikes? > To avoid those latency spikes, limit the number of pages freed > in a single bulk operation to common batch limits. > And how large are they after this? > --- > mm/page_alloc.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index a663202045dc..64a6f9823c8c 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -2215,12 +2215,15 @@ void drain_zone_pages(struct zone *zone, struct per_cpu_pages *pcp) > */ > static void drain_pages_zone(unsigned int cpu, struct zone *zone) > { > - struct per_cpu_pages *pcp; > + struct per_cpu_pages *pcp = per_cpu_ptr(zone->per_cpu_pageset, cpu); > + int count = READ_ONCE(pcp->count); > + > + while (count) { > + int to_drain = min(count, pcp->batch << CONFIG_PCP_BATCH_SCALE_MAX); > + count -= to_drain; > > - pcp = per_cpu_ptr(zone->per_cpu_pageset, cpu); > - if (pcp->count) { > spin_lock(&pcp->lock); > - free_pcppages_bulk(zone, pcp->count, pcp, 0); > + free_pcppages_bulk(zone, to_drain, pcp, 0); > spin_unlock(&pcp->lock); > } I'm not seeing what prevents two CPUs from trying to free the same pages simultaneously?