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 X-Spam-Level: X-Spam-Status: No, score=-17.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75A55C47087 for ; Fri, 28 May 2021 08:50:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E8864613B5 for ; Fri, 28 May 2021 08:50:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8864613B5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5353D6B0070; Fri, 28 May 2021 04:50:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E5046B0071; Fri, 28 May 2021 04:50:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 310AF6B0072; Fri, 28 May 2021 04:50:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id F14406B0070 for ; Fri, 28 May 2021 04:50:12 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7B7C41808F577 for ; Fri, 28 May 2021 08:50:12 +0000 (UTC) X-FDA: 78190017864.36.66F3818 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf30.hostedemail.com (Postfix) with ESMTP id B62EEE000255 for ; Fri, 28 May 2021 08:50:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622191811; 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=0XZKPsGw6GrAtOCDzNONwgIiPoDYBZOFsZ8oGll8uo0=; b=HV7O3cHlKsBws7Qin351b4VDYB6TfM+a3MisL+5iQMT0Z204bpnrTH5UF+LDryboMuUQ1s Es1gCE2k5HjwKns+5H7JLgERbAHNazZSMLVdJYN0mprhKPheaXaG5d99eW3NItKhf2OSKa Y18D7i50JbWwMZHXhVTzd2N17PY80E4= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-13-u8OTqURRNAKtsvru4G3nYQ-1; Fri, 28 May 2021 04:50:09 -0400 X-MC-Unique: u8OTqURRNAKtsvru4G3nYQ-1 Received: by mail-wm1-f72.google.com with SMTP id f141-20020a1c1f930000b029017ce5240ed6so1112793wmf.5 for ; Fri, 28 May 2021 01:50:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0XZKPsGw6GrAtOCDzNONwgIiPoDYBZOFsZ8oGll8uo0=; b=J9exrPkfZ7XPfHdpvp/lchTB5oteE5XAjq/U4WCA410x4ODhZf2ba6Ox6mPuzlX9lP H3AGw7xH2JbmLpQRSF/xzRz+5ee5ghX6ZNuxvYnH7PaqzbnirVVb6rGI14fuKfePvkDW LPfDZ7HLSxFOfZKCITZMR3fZon2AuNvcR72zDS0OLRMNDF546M4G/qCLMSJoMHaprUvA +Z6fMZDXd5DXzIo2pj+omHXfu66fjF+Wr08vD8TRt1xQfsnbwz2bh1f6++TkSbv5izHx zWrlI5MybjWLIc2UNMNZKS31IG/roF0s0cjjcN1oIfJvsAwPu7Yded/TJvwPzzyluNZZ pnXA== X-Gm-Message-State: AOAM530CWg8ARtjbN2aFJ4p+H2gbg5yts3sLJp2qOQ0EheWKxq0j5RrJ pXizJxyTeldcYmSmXZZO2dlkYBNjvwhm3AcmmPmSn9BH3lfcuLzYhnyp00OXEmCc+lEiaLWe1ZM hTEolpc/qALQ= X-Received: by 2002:a05:6000:1b8f:: with SMTP id r15mr7322020wru.119.1622191808385; Fri, 28 May 2021 01:50:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFZL0q+0JcPk4npjBSe+kUXDGPvMOjcmIpNxnzx2+BmPbZA9u8srUPS5pgO8zRey8hxOQ3dg== X-Received: by 2002:a05:6000:1b8f:: with SMTP id r15mr7321984wru.119.1622191808061; Fri, 28 May 2021 01:50:08 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6870.dip0.t-ipconnect.de. [91.12.104.112]) by smtp.gmail.com with ESMTPSA id g6sm6119515wmg.10.2021.05.28.01.50.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 May 2021 01:50:07 -0700 (PDT) Subject: Re: [PATCH RFC] mm,memory_hotplug: Drop unneeded locking To: Oscar Salvador , Andrew Morton Cc: Michal Hocko , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20210528075155.358-1-osalvador@suse.de> From: David Hildenbrand Organization: Red Hat Message-ID: Date: Fri, 28 May 2021 10:50:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20210528075155.358-1-osalvador@suse.de> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HV7O3cHl; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf30.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: ey3jfb644kxtz49n9pjjm7gxhehnfiij X-Rspamd-Queue-Id: B62EEE000255 X-Rspamd-Server: rspam02 X-HE-Tag: 1622191805-813077 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: On 28.05.21 09:51, Oscar Salvador wrote: > Currently, memory-hotplug code takes zone's span_writelock > and pgdat's resize_lock when resizing the node/zone's spanned > pages via {move_pfn_range_to_zone(),remove_pfn_range_from_zone()} > and when resizing node and zone's present pages via > adjust_present_page_count(). > > These locks are also taken during the initialization of the system > at boot time, where it protects parallel struct page initialization, > but they should not really be needed in memory-hotplug where all > operations are a) synchronized on device level and b) serialized by > the mem_hotplug_lock lock. > > Signed-off-by: Oscar Salvador > --- > During the review of [1], it was brought up that we might need to revisit > the locking scheme in memory-hotplug code wrt. node and zone locks. > Given that memory-hotplug is serialized and synchronized by memory-hotplug lock > and the device, I do not think we need to hold zone/node's resize lock anymore. > After the system has been brought up, memory-hotplug is the only code allow to > touch {spanned,present}_pages, so it cannot really go off when serialized by its > own lock. Or am I missing something? > The only think I am not really sure is: if the from remove_pfn_range_from_zone, > shrink_zone_span, update_pgdat_span and move_pfn_range_to_zone can really go > (because those functions are already serialized by the memory-hotplug lock), > what about mhp_(de)init_memmap_on_memory that calls those functions? > Those are not protected by the lock. I have to confess that when it comes to locking > in this code, I always have to scratch my head. > Whenever onlining/offlining memory blocks we're holding the device hotplug lock. So memory hot(un)plug code is completely synchronized. If necessary at some point, we could pull the memory hotplug lock further out. But I doubt it is necessary at this point. AFAIK, memory hot(un)plug isn't possible while we're still initializing the memmap, so this should be fine. > [1] https://patchwork.kernel.org/project/linux-mm/patch/20210416112411.9826-4-osalvador@suse.de/ > > mm/memory_hotplug.c | 10 ---------- > 1 file changed, 10 deletions(-) > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index 075b34803fec..6edd7e267cad 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -329,7 +329,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn, > unsigned long pfn; > int nid = zone_to_nid(zone); > > - zone_span_writelock(zone); > if (zone->zone_start_pfn == start_pfn) { > /* > * If the section is smallest section in the zone, it need > @@ -362,7 +361,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn, > zone->spanned_pages = 0; > } > } > - zone_span_writeunlock(zone); > } > > static void update_pgdat_span(struct pglist_data *pgdat) > @@ -424,10 +422,8 @@ void __ref remove_pfn_range_from_zone(struct zone *zone, > > clear_zone_contiguous(zone); > > - pgdat_resize_lock(zone->zone_pgdat, &flags); > shrink_zone_span(zone, start_pfn, start_pfn + nr_pages); > update_pgdat_span(pgdat); > - pgdat_resize_unlock(zone->zone_pgdat, &flags); > > set_zone_contiguous(zone); > } > @@ -639,14 +635,10 @@ void __ref move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn, > clear_zone_contiguous(zone); > > /* TODO Huh pgdat is irqsave while zone is not. It used to be like that before */ I think you can drop this comment now as well. Acked-by: David Hildenbrand -- Thanks, David / dhildenb