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 D7FE1C433EF for ; Thu, 24 Mar 2022 01:54:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 315456B0072; Wed, 23 Mar 2022 21:54:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C47B6B0073; Wed, 23 Mar 2022 21:54:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 13F4B6B0074; Wed, 23 Mar 2022 21:54:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id F1ED26B0072 for ; Wed, 23 Mar 2022 21:54:43 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C979E241F0 for ; Thu, 24 Mar 2022 01:54:43 +0000 (UTC) X-FDA: 79277610846.12.5DA3585 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf31.hostedemail.com (Postfix) with ESMTP id 694AA20029 for ; Thu, 24 Mar 2022 01:54:43 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id n18so3292415plg.5 for ; Wed, 23 Mar 2022 18:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language :from:to:cc:references:in-reply-to:content-transfer-encoding; bh=5xFwyZQn73GiPXyq1YVWAGYDwDxTo0mcS9yr/vK3q+I=; b=NTjQT4wfv1bF1WAOulMAeTcwlFhQLikQjBdkuwFIwWw0ap7Gu1VhN31OpC68yYaRXb HPEjzKxczn7+Xte0T/GoFcGSqe4pqVmSPx6IwdV6osE4E3Q+fuEPEoReHgVp7Qo8Rcje QWph/9qJl6TJjpwnBf/+8zBT8meytTlh87w773WOfMR5MBmGPp6NzH/YsB5a/SZ7rJBq otLz8c3Ng/4k8EPWea663hnTitLwKFG8pAOtjDS+AFqJod1J2hRCUYMPRj784yIRB1SC 3jXCgUrcSeLPznPGUqlpLj/yqvflQubEElWRdZ0LdYx+DIMcUO+d91Pw4vFJ1f4SpPzC GdRw== 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:from:to:cc:references:in-reply-to :content-transfer-encoding; bh=5xFwyZQn73GiPXyq1YVWAGYDwDxTo0mcS9yr/vK3q+I=; b=kCmaIp4Pwxr2eSONPEv73iGNEFcj98qq32hvKo6ULOct8YEJ3Cngaktt0l13JflRSB OdmBWx7Lsioor2FNR1GWC1UTYSvYUwDvzAEfad5YQowtqEKo6RqMkfJ/7lx36Oa/Nryb 1jHgB7Tb4f1H6Aecqo0bp3NyQQYqcKhZ6QDiymY6O/pieH/Rqb/G8EytW4NkiGcOUYJo BW4oWztnL5Ms6QRWVfkVCEL8FMQCUF+LkIsMeD+xnrp4IOlXKozWmoi0QcG6FRDf5Yab GWijfltXVYO8VTqd+940NyCT2KqyWl6N3gicBwLFdwNA/DCG//Ql1t5CoQmyho3ex3xc /+9A== X-Gm-Message-State: AOAM532NuhvI4e7N4AlJLSpvViU3xOfVSCnlxxQQw7h1c4TEkxeGPYPp WBh8UA2XtezOjUB4LK0BCxUv8g== X-Google-Smtp-Source: ABdhPJyU0EiCFf6aY3cb3clvbdf/wMIXSjp3NY2O+m8f80TaJNb9ba07KjhmV3v7hKT1z40jURF/tg== X-Received: by 2002:a17:903:244d:b0:154:3bb0:7b8c with SMTP id l13-20020a170903244d00b001543bb07b8cmr3167332pls.115.1648086882238; Wed, 23 Mar 2022 18:54:42 -0700 (PDT) Received: from ?IPV6:2600:1700:38d4:55df:aed0:ee00:7944:65f6? ([2600:1700:38d4:55df:aed0:ee00:7944:65f6]) by smtp.gmail.com with ESMTPSA id d2-20020a056a0024c200b004f6b6817549sm1151670pfv.173.2022.03.23.18.54.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Mar 2022 18:54:40 -0700 (PDT) Message-ID: Date: Wed, 23 Mar 2022 18:54:37 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [RFC PATCH 10/47] mm: asi: Support for global non-sensitive direct map allocations Content-Language: en-US From: Junaid Shahid To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, pbonzini@redhat.com, jmattson@google.com, pjt@google.com, oweisse@google.com, alexandre.chartre@oracle.com, rppt@linux.ibm.com, dave.hansen@linux.intel.com, peterz@infradead.org, tglx@linutronix.de, luto@kernel.org, linux-mm@kvack.org References: <20220223052223.1202152-1-junaids@google.com> <20220223052223.1202152-11-junaids@google.com> <3a7c3a71-0be7-261e-20b7-54b4864eedb5@google.com> In-Reply-To: <3a7c3a71-0be7-261e-20b7-54b4864eedb5@google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 694AA20029 X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=NTjQT4wf; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf31.hostedemail.com: domain of junaids@google.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=junaids@google.com X-Stat-Signature: 7w5orfqz7imsxjhku3akmt8yu7orkm4y X-HE-Tag: 1648086883-237925 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000041, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 3/23/22 16:48, Junaid Shahid wrote: > Hi Matthew, > > On 3/23/22 14:06, Matthew Wilcox wrote: >> On Tue, Feb 22, 2022 at 09:21:46PM -0800, Junaid Shahid wrote: >>> standard ASI instances. A new page flag is also added so that when >>> these pages are freed, they can also be unmapped from the ASI page >>> tables. >> >> It's cute how you just throw this in as an aside.  Page flags are >> in high demand and just adding them is not to be done lightly.  Is >> there any other way of accomplishing what you want? >> > > I suppose we may be able to use page_ext instead. That certainly should be > feasible for the PG_local_nonsensitive flag introduced in a later patch, > although I am not completely sure about the PG_global_nonsensitive flag. That > could get slightly tricky (though likely still possible to do) in case we need > to allocate any non-sensitive memory before page_ext is initialized. One concern > with using page_ext could be the extra memory usage on large machines. > > BTW is page flag scarcity an issue on 64-bit systems as well, or only 32-bit > systems? ASI is only supported on 64-bit systems (at least currently). > One other thing that we could do to remove the need for the PG_global_nonsensitive flag altogether (though not the PG_local_nonsensitive flag) would be to always try to unmap pages from the asi_global_nonsensitive_pgd in free_pages(). Basically, that would mean adding a page table walk to every free_pages() rather than just non-sensitive free_pages(). Do you think that may be a better trade-off in order to avoid the flag? Thanks, Junaid