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 967CAC433EF for ; Wed, 1 Jun 2022 14:39:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35F3D8D001F; Wed, 1 Jun 2022 10:39:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30C7D8D001C; Wed, 1 Jun 2022 10:39:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D1F48D001F; Wed, 1 Jun 2022 10:39:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0A9D18D001C for ; Wed, 1 Jun 2022 10:39:53 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D5EBA34873 for ; Wed, 1 Jun 2022 14:39:52 +0000 (UTC) X-FDA: 79529926224.16.20FE4E2 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf17.hostedemail.com (Postfix) with ESMTP id BCA6140053 for ; Wed, 1 Jun 2022 14:39:16 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id l13so3078439lfp.11 for ; Wed, 01 Jun 2022 07:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=31EA6vRKdwEKuRnjDw/ZYtreHn9B2KdDbzd1nRyYZOQ=; b=uVWoHyvzgsqsVh284rkDPfCaL4cl8DXc+3JtebyZYXNFjjb1aE1cOGO5YW3d3b9k/N a3ltGR3Y7zIGFrrS/RmfqjlGFcCB/CkOHIxJizEb9PrGL1PTkLMNOHTrSTpisovoaN4Y KCbz/HRuA6d0ftXtT8uo8zptAsflNcNJN8UkjpkShiQC8oR9R1R1VOj52hJrV/BNFVZk 6TwTVl7LwVVGHdLYwk1fPaFlCMNqXftkg6X7Lrq0B72xuOah6kabVgQ2/PhVIj5Foway dA59fZwUd4i+MY5O0zc0w3f4zQVGVOeYBwb0gvlPnmRkhkrVrcoG4Ocjk1Ddg0yelLl4 D9Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=31EA6vRKdwEKuRnjDw/ZYtreHn9B2KdDbzd1nRyYZOQ=; b=7BNgt29dLpWE13Fdd8uyrlE+Wkj34BO/E6xjkLU5qSDb8bE4dTigwvFFPJO6rd8BZJ 9sqEBftPLqxIig2ZdpzLUDiYQ0B9hUFBkdOPBjATmNCoVTlk2yc+/YhIr1h2QwPvjL0n zxIctNjz1zFWh1fVW81SK69SV4KMfO1Sz+KXNpdE5dCi/DLfuK0qjNQ4knTcyeazRApO pp4kAAr4psVtrifGQ1lR0etTWguGIVvj3O6tLd8iFb9YigaV5gUTHT6z0eZKNzkWz47i iIHBfyJrFEoqT45TNuZKcpMDMKAgvNP+GwqnRMtGGmT0em3cLTyrAU9olNKzg1h8Fzfp Txsw== X-Gm-Message-State: AOAM531CxMgqrAQINrMJVccJkzizL3fqz8vbbp2p2pKv4I0ClRbyC15M o81cE7kgLDND+WJnv3GuDa96Lg== X-Google-Smtp-Source: ABdhPJytzV7/7pe53tLyOeHlbGNCloSYChNpAaJazKo2Ow7frOawx90Wzg5h4MwOnTDSTluYhB+amg== X-Received: by 2002:a05:6512:2255:b0:478:da8f:e2e3 with SMTP id i21-20020a056512225500b00478da8fe2e3mr43581lfu.50.1654094390799; Wed, 01 Jun 2022 07:39:50 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id q23-20020a2e9157000000b002554d2a5ea1sm353365ljg.10.2022.06.01.07.39.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 07:39:50 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id A464F109789; Wed, 1 Jun 2022 17:41:48 +0300 (+03) Date: Wed, 1 Jun 2022 17:41:48 +0300 From: "Kirill A. Shutemov" To: David Hildenbrand Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , 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 Subject: Re: [PATCHv6 15/15] mm/vmstat: Add counter for memory accepting Message-ID: <20220601144148.2saee3gw7jgvusgt@box.shutemov.name> References: <20220517153444.11195-1-kirill.shutemov@linux.intel.com> <20220517153444.11195-16-kirill.shutemov@linux.intel.com> <76adccb2-2925-e102-db6f-529492d885c7@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76adccb2-2925-e102-db6f-529492d885c7@redhat.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BCA6140053 X-Stat-Signature: s7jzt9jes5n9zcm1cigu71wxdabj5si8 X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=uVWoHyvz; spf=none (imf17.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.167.48) smtp.mailfrom=kirill@shutemov.name; dmarc=none X-HE-Tag: 1654094356-43594 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 Wed, Jun 01, 2022 at 11:05:40AM +0200, David Hildenbrand wrote: > 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 That's very serialization happens. We can do it in the core mm if we can tolerate sporious vmcount bump. Otherwise it has to happen under the lock in the arch code. > Also, I'm a bit > confused about the granularity here (PMD_SIZE). That's how we track it in x86. The count itself is in pages. Different arch can choose different granularity. > > /* 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? "still ongoing" in sense it is happening now, like if it increases system does memory accept. > 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. Patch 10/15 does this, but not in buddy. -- Kirill A. Shutemov