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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 B3C85C433B4 for ; Wed, 28 Apr 2021 14:44:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DDB89613F0 for ; Wed, 28 Apr 2021 14:44:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DDB89613F0 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 1ABCD6B0070; Wed, 28 Apr 2021 10:44:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15C736B0071; Wed, 28 Apr 2021 10:44:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED6606B0072; Wed, 28 Apr 2021 10:44:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0224.hostedemail.com [216.40.44.224]) by kanga.kvack.org (Postfix) with ESMTP id CD5306B0070 for ; Wed, 28 Apr 2021 10:44:43 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8602012EF for ; Wed, 28 Apr 2021 14:44:43 +0000 (UTC) X-FDA: 78082047246.18.01CD9DD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 262BC40002D0 for ; Wed, 28 Apr 2021 14:44:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619621082; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VjWuwXa1YtMUwTvGVSDOIM7cAaoA6yJc6vXG9qhAW3A=; b=e1NSLMqTb6TYPaEkRej6vrrOZBrTwWorcDxtd1HLf9KEVcAueilGtpV13lwATxF4+BKTgq YCdkfNHZzi5BNJo3gNejGsTImWvCgGsdK+gha156d+YI4is9ENNkaxR98KjijmT/ri86CN advNJ3lWF6LtxoB6kxTa1YblVfjj/O0= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-21-leNgRJCWMPmwDa-oXy_tCw-1; Wed, 28 Apr 2021 10:44:38 -0400 X-MC-Unique: leNgRJCWMPmwDa-oXy_tCw-1 Received: by mail-wr1-f69.google.com with SMTP id q18-20020adfc5120000b029010c2bdd72adso4570441wrf.16 for ; Wed, 28 Apr 2021 07:44:38 -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:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VjWuwXa1YtMUwTvGVSDOIM7cAaoA6yJc6vXG9qhAW3A=; b=TOHfgGdwc/uqihDHMsGynr3XskQ2TteOjQKM0wiYxznuYFtjVfKOsY3wcrotyl4d6l dAY4aljg+CMv7Q29Df6Q/UqprFL6FgYQAp5kVUCISmczvtGasMjaSRmTLi5lJfjxmDiN rTqGwTGr81Ue8siCjaRNdsoPTXxVFW79oczX/uRgJm+CJ0UGYhGTmWNnuzIhuvA7DY4n B8NO+x0JLwV5FN7l1SERmitMfiQwZuksLKIn4dk0WdMpMBNGNpZ7/csdZjPSZzM096sF Dcltks1I/81ZY4j5qQ02mXsZhFX5VgT0MPwF1fpgA8s/o6MU2PWFe3IpKV/EQ7wGKOBv oEDQ== X-Gm-Message-State: AOAM533ki3Dx72DbMtOxZ4mYNRy3vWCxrs+VbUj6Tfl+R0+s3xRRXM8X y7jWOCnWfykzu0sT9jKTUNqFKxCECtG6ZGrVgzCKZI9gtTOWft6lsdda0SHTKjLymZiyuLbQB5Y 4GfN28+/nxBE= X-Received: by 2002:a7b:c312:: with SMTP id k18mr32218064wmj.89.1619621077314; Wed, 28 Apr 2021 07:44:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw/eTvBZIFZBQvqlxG36XxLa2MkImGigzmxHvgls8vpEbFngdpMJma6FbJTuPACeuAEUlKkHg== X-Received: by 2002:a7b:c312:: with SMTP id k18mr32218040wmj.89.1619621077038; Wed, 28 Apr 2021 07:44:37 -0700 (PDT) Received: from ?IPv6:2003:d8:2f38:2400:62f4:c5fa:ba13:ac32? (p200300d82f38240062f4c5faba13ac32.dip0.t-ipconnect.de. [2003:d8:2f38:2400:62f4:c5fa:ba13:ac32]) by smtp.gmail.com with ESMTPSA id g11sm192970wri.59.2021.04.28.07.44.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Apr 2021 07:44:36 -0700 (PDT) Subject: Re: Is there a different memory allocation path other than the buddy allocator? To: Shivank Garg , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, gregkh@linuxfoundation.org, sergey.senozhatsky@gmail.com, pmladek@suse.com References: From: David Hildenbrand Organization: Red Hat Message-ID: <88d5164f-0261-469c-5549-4d97a7936775@redhat.com> Date: Wed, 28 Apr 2021 16:44:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com 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 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 262BC40002D0 X-Stat-Signature: 8b75m5enab1y6dduowxhnjrtpuztp68d Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf17; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619621079-3309 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.04.21 09:37, Shivank Garg wrote: > Hi Everyone! > > I'm understanding memory allocation in Linux and doing some changes in > buddy allocator (__alloc_pages_nodemask) for my experiments. I create > a new flag in `struct page->flags` (by adding a new flag in `enum > pageflags` in `page-flags.h`. I set this bit permanently in > __alloc_pages_nodemask (to not to be cleared once set and survive all > further allocation and freeing). But I'm not able to see expected > behavior. > > I'm guessing this is because Linux is also using some different path > to allocate memory (probably during boot). Is my hypothesis correct? > > Is there any different memory allocation path other than buddy > allocator? Where can I find it? memblock is the early memory allocator during boot, before the buddy is up and running. The range allocator (e.g., alloc_contig_range()) is some kind of mechanism that builds up on top of the buddy. Other allcoators (hugetlb, slab, ...) might cache some pages, but effectively get "physical memory" either via memblock or the buddy. CMA is another special-purpose allocator which reserves physical memory areas via memblock and then uses the range allocator to actually allocate memory inside these reserved regions at runtime. -- Thanks, David / dhildenb