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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58A14C43334 for ; Tue, 21 Jun 2022 09:29:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348807AbiFUJ3y (ORCPT ); Tue, 21 Jun 2022 05:29:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348739AbiFUJ3x (ORCPT ); Tue, 21 Jun 2022 05:29:53 -0400 Received: from outbound-smtp40.blacknight.com (outbound-smtp40.blacknight.com [46.22.139.223]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18BF4DBF for ; Tue, 21 Jun 2022 02:29:53 -0700 (PDT) Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp40.blacknight.com (Postfix) with ESMTPS id 9E49A1C466F for ; Tue, 21 Jun 2022 10:29:51 +0100 (IST) Received: (qmail 21487 invoked from network); 21 Jun 2022 09:29:51 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 21 Jun 2022 09:29:51 -0000 Date: Tue, 21 Jun 2022 10:29:50 +0100 From: Mel Gorman To: Nicolas Saenz Julienne Cc: Andrew Morton , Marcelo Tosatti , Vlastimil Babka , Michal Hocko , Hugh Dickins , LKML , Linux-MM Subject: Re: [PATCH 7/7] mm/page_alloc: Replace local_lock with normal spinlock Message-ID: <20220621092950.GF15453@techsingularity.net> References: <20220613125622.18628-1-mgorman@techsingularity.net> <20220613125622.18628-8-mgorman@techsingularity.net> <04709b2d0dc702c9bf50f57cde125b07cdf54363.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <04709b2d0dc702c9bf50f57cde125b07cdf54363.camel@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 17, 2022 at 11:39:03AM +0200, Nicolas Saenz Julienne wrote: > Hi Mel, > > On Mon, 2022-06-13 at 13:56 +0100, Mel Gorman wrote: > > @@ -3446,12 +3490,16 @@ void free_unref_page(struct page *page, unsigned int order) > > migratetype = MIGRATE_MOVABLE; > > } > > > > - local_lock_irqsave(&pagesets.lock, flags); > > - freed_pcp = free_unref_page_commit(page, migratetype, order, false); > > - local_unlock_irqrestore(&pagesets.lock, flags); > > - > > - if (unlikely(!freed_pcp)) > > + zone = page_zone(page); > > + pcp_trylock_prepare(UP_flags); > > Now that you're calling the *_irqsave() family of function you can drop > pcp_trylock_prepare/finish() > > For the record in UP: > > #define spin_trylock_irqsave(lock, flags) \ > ({ \ > local_irq_save(flags); \ > 1; > }) > The missing patch that is deferred for a later release uses spin_trylock so unless that is never merged because there is an unfixable flaw in it, I'd prefer to leave the preparation in place. > > + pcp = pcpu_spin_trylock_irqsave(struct per_cpu_pages, lock, zone->per_cpu_pageset, flags); > > + if (pcp) { > > + free_unref_page_commit(pcp, zone, page, migratetype, order); > > + pcp_spin_unlock_irqrestore(pcp, flags); > > + } else { > > free_one_page(page_zone(page), page, pfn, order, migratetype, FPI_NONE); > > + } > > + pcp_trylock_finish(UP_flags); > > } > > > > /* > > As Vlastimil mentioned elsewhere, I also wonder if it makes sense to just > bypass patch #5. Especially as its intent isn't true anymore: > > "As preparation for dealing with both of those problems, protect the lists > with a spinlock. The IRQ-unsafe version of the lock is used because IRQs > are already disabled by local_lock_irqsave. spin_trylock is used in > preparation for a time when local_lock could be used instead of > lock_lock_irqsave." > It's still true, the patch just isn't included as I wanted them to be separated by time so a bisection that points to it is "obvious" instead of pointing at the whole series as being a potential problem. -- Mel Gorman SUSE Labs