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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 546F1C433C1 for ; Thu, 25 Mar 2021 18:09:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CC96D614A7 for ; Thu, 25 Mar 2021 18:09:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC96D614A7 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 33D036B006C; Thu, 25 Mar 2021 14:09:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2ED0D6B006E; Thu, 25 Mar 2021 14:09:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18D9B6B0070; Thu, 25 Mar 2021 14:09:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id F302E6B006C for ; Thu, 25 Mar 2021 14:09:07 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A4E871E0F for ; Thu, 25 Mar 2021 18:09:07 +0000 (UTC) X-FDA: 77959183134.07.B2083E5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 96CAF3535 for ; Thu, 25 Mar 2021 18:08:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616695738; 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=drU5tvVMYvfs+I6S2meKDKFJotJ/fm7RW4NXE7uUIV0=; b=ilPmDQbT90T7PlxMKORLitXA3FH5dC5quq2N5D/Uaj0KLXeAIX7W9Fp0snnzWqksjo89e2 t+FNVrCsUYvjDiS7g0iqVvhRQ7IzqLnTCEpKFFVVug6nqtWfFID455Gfi2fym0XPdh7SiW gpW+tS7k8gGXUN8beSCqKmYcFu/OI+0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-362-oRnjcgSyPHi1ps1zZeKWrg-1; Thu, 25 Mar 2021 14:08:54 -0400 X-MC-Unique: oRnjcgSyPHi1ps1zZeKWrg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8FBD1835B74; Thu, 25 Mar 2021 18:08:08 +0000 (UTC) Received: from [10.36.115.72] (ovpn-115-72.ams2.redhat.com [10.36.115.72]) by smtp.corp.redhat.com (Postfix) with ESMTP id 924EE1A8F2; Thu, 25 Mar 2021 18:08:06 +0000 (UTC) To: Michal Hocko Cc: Oscar Salvador , Andrew Morton , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <31110e58-c99a-8dee-6f6e-98f456b77759@redhat.com> <062bc5d7-a83c-1c1a-7b77-9f043643f4fa@redhat.com> <31c3e6f7-f631-7b00-2c33-518b0f24a75f@redhat.com> <40fac999-2d28-9205-23f0-516fa9342bbe@redhat.com> <92fe19d0-56ac-e929-a9c1-d6a4e0da39d1@redhat.com> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v5 1/5] mm,memory_hotplug: Allocate memmap from the added memory range Message-ID: <5a755ff6-4085-da64-08d5-49dd232029eb@redhat.com> Date: Thu, 25 Mar 2021 19:08:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Stat-Signature: qa8c8wx7thccyxa8nurhpjd3i6gik5j6 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 96CAF3535 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616695737-10660 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: On 25.03.21 17:36, Michal Hocko wrote: > On Thu 25-03-21 17:20:23, David Hildenbrand wrote: >> On 25.03.21 17:07, Michal Hocko wrote: >>> On Thu 25-03-21 16:35:58, Michal Hocko wrote: >>> [...] >>>> So there is indeed a difference. One way around that would be to mar= k >>>> vmemmap pages (e.g. PageReserved && magic value stored somewhere in = the >>>> struct page - resembling bootmem vmemmaps) or mark section fully bac= king >>>> vmemmaps as online (ugly). >>> >>> I am not yet ready to give up on this. Here is a quick stab at the >>> pfn_to_online_page approach. It is not great but it is not really >>> terrible either. I think we can do better and skip >> >> We both seem to have a different taste, to phrase it in a nice way :) = ; but >> well, you seem to have set your mind (just like I seem to have set min= e when >> trying to find a nice and somewhat-clean way to handle this when discu= ssing >> it in the past). >=20 > I definitely do not want to fight for a certain solution just for the > sake of it. I really dislike how the lifetime of the reserved space and > its accounting are completely detached. But hey, I do understand that > a worse solution from the design perspective can be better due to > practical reasons or constrains. >=20 > I haven't seen the hibernation problem before and I do recognize it is > a nasty one. If all it takes is to make pfn_to_online_page work (and my > previous attempt is incorrect because it should consult block rather > than section pfn range) and there are no other downsides then I would > still prefer to go with my proposal. If there are still other things t= o > plug then, well, practicality is going to win. >=20 > So before I give up on the "proper" design card, are there more > subtleties to watch for? You have certainly given this much more though= t > than I have. >=20 "Just one more thing" :) With the pfn_to_online_page() change, I think what remains is 1. The contiguous zone thingy, which we discussed is not a deal breaker,=20 although sub-optimal and most probably not to be optimized in the future. 2. There corner cases issue with /dev/mem use case with offline memory=20 blocks I mentioned. Existing setups (!memmap_on_memory) are not=20 affected, so I guess we're fine. 3. valid_zones_show() has to be taught to only look at the !vmemmap=20 part, otherwise we'll no longer indicate "movable" after onlining to the=20 movable zone. Should be fairly easy. We'll have pfn_to_online_section() succeed without SECTION_IS_ONLINE. I=20 think I/we removed all such code that purely relied on that flag for=20 optimizations like if (!online_section(s)) continue; I can give it some more thought, it could fly. At least zone shrinking=20 and hibernation should continue working as expected, which is a relief. --=20 Thanks, David / dhildenb