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 48D68C433FE for ; Wed, 5 Oct 2022 18:09:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB0CC6B0072; Wed, 5 Oct 2022 14:09:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C608B6B0073; Wed, 5 Oct 2022 14:09:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ADA096B0074; Wed, 5 Oct 2022 14:09: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 982496B0072 for ; Wed, 5 Oct 2022 14:09:36 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BD164AB679 for ; Wed, 5 Oct 2022 18:09:35 +0000 (UTC) X-FDA: 79987683510.06.AA9BE73 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 7593140003 for ; Wed, 5 Oct 2022 18:09:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664993373; 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=EILNfA7N9+8iFvHlpQy0LTguKHZxy+BH1aj+G4n/6Fg=; b=DXv+0y/Ff+db3jwW6lHpgRQSdFZJDjeBXgL2wnaou7W2HSH3z3d/Idfypk12t+k8ksotfJ XzoYcK8M7AdQa8Kh7wOwMBslS625F+mGp1dkoZZebLjERaJ8KzQDflNZQZlXAQ3NkQOc1w 4nzUnnmCxXaaVK2+9oGTJOTv0eXdeu8= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-482-TKbtC4UbM7mbRp2Uycyv-g-1; Wed, 05 Oct 2022 14:09:32 -0400 X-MC-Unique: TKbtC4UbM7mbRp2Uycyv-g-1 Received: by mail-wm1-f72.google.com with SMTP id b7-20020a05600c4e0700b003bde2d860d1so676928wmq.8 for ; Wed, 05 Oct 2022 11:09:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :content-language:references:cc:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date; bh=EILNfA7N9+8iFvHlpQy0LTguKHZxy+BH1aj+G4n/6Fg=; b=BFc296okZJUvEmG4Z0Ww8jnn3AULlUT8AARG0bGqoBN7dA6S+OwoH5WUQtfF7yohIJ t1ZNVV+6MwhMzot/J4nYdXi6ilXyWOYSTwaUCeiO00W/u78KY9mEYpN2/RZwTtcgVvxx t3qmBRhpCeuhwFuflQ/rSZy5VpYPEnj5ClpxfuZIDnzXZ3kBviy4SKKqYNnrxFt6KfPI 5M5QbSam0fJnqGiEj8xUP+BplUmEC1qPSSbm7RlNFyERljqmyukXN2160PlltqTO+yDT mKQoW10upFfYTT3JKOThLyvQ9gdsmYoInl079ILDzMfriw7v1AgS7XRyagfUo7RSLNBa A5eQ== X-Gm-Message-State: ACrzQf2BVdVUIBV5ZrbtKGeWgNvUTwSfMofAV+8FebKd4FbuT3cN062o HnmKs+/XUraAx6xt3JF3p5wKhRYk7oB+apIyQmkeYl7CZ382xRvL+qvQd5CMHv23gs/oboPEcYo vjr4mR4C87Js= X-Received: by 2002:a5d:6a42:0:b0:22e:6706:647b with SMTP id t2-20020a5d6a42000000b0022e6706647bmr642980wrw.58.1664993371130; Wed, 05 Oct 2022 11:09:31 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6GWHac6uT0D+X91ERTzLNHZyPlhzgA2jM5+WzKEJoau6td1MXwIP/Qp+dZqdNDDL+WY0UZDg== X-Received: by 2002:a5d:6a42:0:b0:22e:6706:647b with SMTP id t2-20020a5d6a42000000b0022e6706647bmr642956wrw.58.1664993370783; Wed, 05 Oct 2022 11:09:30 -0700 (PDT) Received: from ?IPV6:2003:cb:c702:5a00:b732:1c9:3697:fccf? (p200300cbc7025a00b73201c93697fccf.dip0.t-ipconnect.de. [2003:cb:c702:5a00:b732:1c9:3697:fccf]) by smtp.gmail.com with ESMTPSA id f11-20020a05600c154b00b003a3442f1229sm3123817wmg.29.2022.10.05.11.09.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Oct 2022 11:09:30 -0700 (PDT) Message-ID: <84ee3d9e-9579-d3f2-fe5a-ec6ec4a2710a@redhat.com> Date: Wed, 5 Oct 2022 20:09:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 To: Doug Berger , Andrew Morton Cc: Jonathan Corbet , Mike Rapoport , Borislav Petkov , "Paul E. McKenney" , Neeraj Upadhyay , Randy Dunlap , Damien Le Moal , Muchun Song , KOSAKI Motohiro , Mel Gorman , Mike Kravetz , Florian Fainelli , Oscar Salvador , Michal Hocko , Joonsoo Kim , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20220928223301.375229-1-opendmb@gmail.com> <20220928223301.375229-3-opendmb@gmail.com> <8e61d0f4-0c40-6c2d-da60-fa97e2ee7530@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v2 2/9] mm/vmstat: show start_pfn when zone spans pages In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664993374; a=rsa-sha256; cv=none; b=8WhYtqF6T7AJvQvb650VyEW/JzGhlWPCVFElNebrq48XN7LTxkdCxIM0M4OAigvnmLcN2V QiWfMHeq/3Y2jA+GySCrnoBlq+mur92OJ5SxRNk793oloM9VPF8Ku0seI2NIFrMnx4GRKc vwd/BScywK50Rsplr5ih42MgVXXh0DE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="DXv+0y/F"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664993374; 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=EILNfA7N9+8iFvHlpQy0LTguKHZxy+BH1aj+G4n/6Fg=; b=298nuHPotpYFrgpXCXg//2CG/0usfc5FyqTOUsr1/xkUgFKyJDPDwsjSAeUOrATyGm3MTI 8QsosXRBctcjBZnHdhq9haECuTlZG64D3y3KnnD/YRqVcvaEJe6qQVOWABZkCFdrO+O/8H vTP1Fmej9pBEfv4Fm+Q7auAQuGfSZUI= X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="DXv+0y/F"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com X-Stat-Signature: ihbqkqcftztzponmn8nqn8gfphttfynb X-Rspamd-Queue-Id: 7593140003 X-Rspamd-Server: rspam09 X-HE-Tag: 1664993374-786117 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 01.10.22 03:28, Doug Berger wrote: > On 9/29/2022 1:15 AM, David Hildenbrand wrote: >> On 29.09.22 00:32, Doug Berger wrote: >>> A zone that overlaps with another zone may span a range of pages >>> that are not present. In this case, displaying the start_pfn of >>> the zone allows the zone page range to be identified. >>> >> >> I don't understand the intention here. >> >> "/* If unpopulated, no other information is useful */" >> >> Why would the start pfn be of any use here? >> >> What is the user visible impact without that change? > Yes, this is very subtle. I only caught it while testing some > pathological cases. > > If you take the example system: > The 7278 device has four ARMv8 CPU cores in an SMP cluster and two > memory controllers (MEMCs). Each MEMC is capable of controlling up to > 8GB of DRAM. An example 7278 system might have 1GB on each controller, > so an arm64 kernel might see 1GB on MEMC0 at 0x40000000-0x7FFFFFFF and > 1GB on MEMC1 at 0x300000000-0x33FFFFFFF. > Okay, thanks. You should make it clearer in the patch description -- especially how this relates to DMB. Having that said, I still have to digest your examples: > Placing a DMB on MEMC0 with 'movablecore=256M@0x70000000' will lead to > the ZONE_MOVABLE zone spanning from 0x70000000-0x33fffffff and the > ZONE_NORMAL zone spanning from 0x300000000-0x33fffffff. Why is ZONE_MOVABLE spanning more than 256M? It should span 0x70000000-0x80000000 Or what am I missing? > > If instead you specified 'movablecore=256M@0x70000000,512M' you would > get the same ZONE_MOVABLE span, but the ZONE_NORMAL would now span > 0x300000000-0x32fffffff. The requested 512M of movablecore would be > divided into a 256MB DMB at 0x70000000 and a 256MB "classic" movable > zone start would be displayed in the bootlog as: > [ 0.000000] Movable zone start for each node > [ 0.000000] Node 0: 0x000000330000000 Okay, so that's the movable zone range excluding DMB. > > Finally, if you specified the pathological > 'movablecore=256M@0x70000000,1G@12G' you would still have the same > ZONE_MOVABLE span, and the ZONE_NORMAL span would go back to > 0x300000000-0x33fffffff. However, because the second DMB (1G@12G) > completely overlaps the ZONE_NORMAL there would be no pages present in > ZONE_NORMAL and /proc/zoneinfo would report ZONE_NORMAL 'spanned > 262144', but not where those pages are. This commit adds the 'start_pfn' > back to the /proc/zoneinfo for ZONE_NORMAL so the span has context. ... but why? If there are no pages present, there is no ZONE_NORMAL we care about. The zone span should be 0. Does this maybe rather indicate that there is a zone span processing issue in your DMB implementation? Special-casing zones based on DMBs feels wrong. But most probably I am missing something important :) -- Thanks, David / dhildenb