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 B6500C433EF for ; Wed, 1 Jun 2022 09:05:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E3B36B0098; Wed, 1 Jun 2022 05:05:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4BA6A6B0099; Wed, 1 Jun 2022 05:05:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A3316B009A; Wed, 1 Jun 2022 05:05:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 291C76B0098 for ; Wed, 1 Jun 2022 05:05:47 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F2610341AC for ; Wed, 1 Jun 2022 09:05:46 +0000 (UTC) X-FDA: 79529084292.21.EE02273 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 8D88F1C0049 for ; Wed, 1 Jun 2022 09:05:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654074346; 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=LJrHD/fk/T3aZT3PXrEdxCfOFI/2TTZWKV2+KGqpvvM=; b=aNGf2iRmXCzzIGp2B58fd7be9Ft6UN+m4e6D6Ibopcat1uCbWk3Z5SFCd8k1VTHYuhbaOE BeUmeedvj9w8hvg+DTT2+5d2GACPjP1wmNszpNPpuvukixkdAc8PY4RyT5mF+kCPyjW+1R BL3flYIjH/F5qDsVHSE+l6VFmSQ+X60= 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.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-21-UiU_rKr3OmWeKdnp53uj3w-1; Wed, 01 Jun 2022 05:05:44 -0400 X-MC-Unique: UiU_rKr3OmWeKdnp53uj3w-1 Received: by mail-wm1-f72.google.com with SMTP id bg13-20020a05600c3c8d00b003974d0ff917so824150wmb.3 for ; Wed, 01 Jun 2022 02:05:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=LJrHD/fk/T3aZT3PXrEdxCfOFI/2TTZWKV2+KGqpvvM=; b=OHvXCI2den1zP9Q2sW3ZFgbhFZlE+GaKtci6Es6DbCkKNFQYGossV2o/5ZWa7XTfsL RkDFQKwDPdzGw7hamKVDjy0o78bwk/qpEtQK01S/hLmOvOcTXeZSTVqiggr/t14LO70R wcIfJEWdlO53oyZ8pPUxtPjvdkB7FfucCoAeWYmGNUhcu4UM2GQHdxwzHlzsLP5Aml4M dXlD+r+Aq7BwUNdftueY/m4sTdpAbeGcV7WJDJPpyFFcM5B+eDa4WqNvSboUifCeScUL Q5boR8pAPZD2wJqmOd+JmoE4Q5/gxhH5ZrB/OOdbmaURPSafsBfPkzB9zOpgMDFJ7hKW VikA== X-Gm-Message-State: AOAM5318uGhcusSSc8IZI1s9TA3Y5fByc5MVTtt1KMKhsIFrmJeEPF4o EaT67N+J37HYSLg+eiP/OVjllZo/oFXUZuQ0Qb/xGot4HD0RH4GV4m/x8lB7LYVE6Q32UqWsQFM gKlsKY2ivI7I= X-Received: by 2002:adf:fc01:0:b0:20c:ff9a:2c53 with SMTP id i1-20020adffc01000000b0020cff9a2c53mr52818620wrr.142.1654074343771; Wed, 01 Jun 2022 02:05:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwxI/IEgL1kUl8RIGZMf6kss0Qr5WfcXWB8YjnOXt3Enet6ufD7u1NcX/gWzDd47wFHqRyvYg== X-Received: by 2002:adf:fc01:0:b0:20c:ff9a:2c53 with SMTP id i1-20020adffc01000000b0020cff9a2c53mr52818592wrr.142.1654074343514; Wed, 01 Jun 2022 02:05:43 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:2600:951d:63df:c091:3b45? (p200300cbc7052600951d63dfc0913b45.dip0.t-ipconnect.de. [2003:cb:c705:2600:951d:63df:c091:3b45]) by smtp.gmail.com with ESMTPSA id n22-20020a05600c3b9600b00397342e3830sm7173656wms.0.2022.06.01.02.05.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jun 2022 02:05:42 -0700 (PDT) Message-ID: <76adccb2-2925-e102-db6f-529492d885c7@redhat.com> Date: Wed, 1 Jun 2022 11:05:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCHv6 15/15] mm/vmstat: Add counter for memory accepting To: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel Cc: Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Dave Hansen , Mike Rapoport , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220517153444.11195-1-kirill.shutemov@linux.intel.com> <20220517153444.11195-16-kirill.shutemov@linux.intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220517153444.11195-16-kirill.shutemov@linux.intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8D88F1C0049 X-Stat-Signature: kp7z548d7nr4rrueq5xqauaqxk8c35uc X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aNGf2iRm; spf=none (imf18.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1654074326-28560 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 17.05.22 17:34, Kirill A. Shutemov wrote: > The counter increased every time kernel accepts a memory region. > > The counter allows to see if memory acceptation is still ongoing and > contributes to memory allocation latency. > > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/mm/unaccepted_memory.c | 1 + > include/linux/vm_event_item.h | 3 +++ > mm/vmstat.c | 3 +++ > 3 files changed, 7 insertions(+) > > diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c > index 6ecd79101922..fe1dabfae326 100644 > --- a/arch/x86/mm/unaccepted_memory.c > +++ b/arch/x86/mm/unaccepted_memory.c > @@ -74,6 +74,7 @@ void accept_memory(phys_addr_t start, phys_addr_t end) > } > > bitmap_clear(bitmap, range_start, len); > + count_vm_events(ACCEPT_MEMORY, len * PMD_SIZE / PAGE_SIZE); > It's a bit weird that this is accounted from arch code. Also, I'm a bit confused about the granularity here (PMD_SIZE). > /* In early boot nr_unaccepted is not yet initialized */ > if (nr_unaccepted) { > diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h > index 16a0a4fd000b..6a468164a2f9 100644 > --- a/include/linux/vm_event_item.h > +++ b/include/linux/vm_event_item.h > @@ -136,6 +136,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT, > #ifdef CONFIG_X86 > DIRECT_MAP_LEVEL2_SPLIT, > DIRECT_MAP_LEVEL3_SPLIT, > +#endif > +#ifdef CONFIG_UNACCEPTED_MEMORY > + ACCEPT_MEMORY, > #endif > NR_VM_EVENT_ITEMS > }; > diff --git a/mm/vmstat.c b/mm/vmstat.c > index b75b1a64b54c..4c9197f32406 100644 > --- a/mm/vmstat.c > +++ b/mm/vmstat.c > @@ -1397,6 +1397,9 @@ const char * const vmstat_text[] = { > "direct_map_level2_splits", > "direct_map_level3_splits", > #endif > +#ifdef CONFIG_UNACCEPTED_MEMORY > + "accept_memory", > +#endif > #endif /* CONFIG_VM_EVENT_COUNTERS || CONFIG_MEMCG */ > }; > #endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA || CONFIG_MEMCG */ How exactly would I be able to figure out if "memory acceptation is still ongoing" if there is one last remaining page stuck at the tail of the freelist? Wouldn't it make more sense to actually count the number of unaccepted pages in the buddy? Once that number drops to 0, one knows that there is no unaccepted memory left in the buddy. -- Thanks, David / dhildenb