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 6C370C433F5 for ; Wed, 23 Mar 2022 23:49:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D474D6B0072; Wed, 23 Mar 2022 19:49:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF6966B0073; Wed, 23 Mar 2022 19:49:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B974D6B0074; Wed, 23 Mar 2022 19:49:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0062.hostedemail.com [216.40.44.62]) by kanga.kvack.org (Postfix) with ESMTP id A93E96B0072 for ; Wed, 23 Mar 2022 19:49:02 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4D8E018289DE4 for ; Wed, 23 Mar 2022 23:49:02 +0000 (UTC) X-FDA: 79277294124.28.6E43F48 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf09.hostedemail.com (Postfix) with ESMTP id D1687140021 for ; Wed, 23 Mar 2022 23:49:01 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id k6so3057771plg.12 for ; Wed, 23 Mar 2022 16:49:01 -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:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=OqY1xTeVRlw2nfYyxxPoQU/LOGXlMjj+SpATPbEYmHk=; b=QPglaTyMq/OcPmXLWAnAvpGHghRviGDrt5W9reAcKupVIszxI8a6HgU8atAN5p8bd2 XSNMBxzaLe/XNjMPXpZ47CWOTtp0wNGcjxu30YaBrv7SHHr3/LgVb5kzxCKIEyK35gmQ 5SDHpHMC5ZwEGYGPGd8OHpxYIBoQudDrOchfOhg+0ocWziqEtPkjjSDpoW9527AiDJX6 MaiXtTYGfq2GQXCsO+Y3bjDDNqRUPCMlzDnHRQXV50J4Cm/xEo+4tuuK805aocqGzS1o Os6w0vupztZM/VelhVI1KwYsHM4YC1Zt8Ak9Fws20xETp+XRrxCRColPxu2RmdZOKONr 0CmA== 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:in-reply-to :content-transfer-encoding; bh=OqY1xTeVRlw2nfYyxxPoQU/LOGXlMjj+SpATPbEYmHk=; b=LX3vOufKnXGQ1NPP4EE9aVhPHbn4NfojZT7Zi2MHAV5C3Ymvh1aW/8p479eF5XOy3X G/MXeEbxXrFt9Zw+zX/jOW6DnD6Sc11dNsrcpFUx4Op6/KJU6VZ6hh23JYt9TOUV2GPY 5ndoEYEdZRZ/OlFTYORWGdCFC45O5hajY1peON33THfcqwYOfb04RGeCDB6uqA/0GwG2 OTF97qIQ4MyHBX7F3huUBqrnBCOALlkdcU5qNGQtriB+g0mWafn7hMTB3bXpwwGkYlXx NvJKfGoTh3d8Rv7VlUXBbKqTG6Q+s0rJzfdaP618U5mpKS8EEIgPISvFVeQAveyLU25S KD7g== X-Gm-Message-State: AOAM530k2jD9RHf1mF7RivfamdGjNLk6Fsn/6PzeAy9yk399XADPz0xX UMBcIDt4BDrZiA+BJFeEdfqyow== X-Google-Smtp-Source: ABdhPJxlBFuH7Nhi8Qp9G1SpsD27wA5t3nVbN3x89MKrvpsFO3GJ9or400etjmvjzNtg0wD6aIwTHw== X-Received: by 2002:a17:903:1205:b0:151:8ae9:93ea with SMTP id l5-20020a170903120500b001518ae993eamr2691148plh.37.1648079340546; Wed, 23 Mar 2022 16:49:00 -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 124-20020a621682000000b004f6a2e59a4dsm921771pfw.121.2022.03.23.16.48.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Mar 2022 16:48:59 -0700 (PDT) Message-ID: <3a7c3a71-0be7-261e-20b7-54b4864eedb5@google.com> Date: Wed, 23 Mar 2022 16:48:57 -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 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> From: Junaid Shahid In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D1687140021 X-Stat-Signature: e3ba53edbf3qcpbjg8uzoxttt9iwknpi Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=QPglaTyM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of junaids@google.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=junaids@google.com X-Rspam-User: X-HE-Tag: 1648079341-174620 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000017, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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). >> @@ -542,6 +545,12 @@ TESTCLEARFLAG(Young, young, PF_ANY) >> PAGEFLAG(Idle, idle, PF_ANY) >> #endif >> >> +#ifdef CONFIG_ADDRESS_SPACE_ISOLATION >> +__PAGEFLAG(GlobalNonSensitive, global_nonsensitive, PF_ANY); > > Why is PF_ANY appropriate? > I think we actually can use PF_HEAD here. That would make the alloc_pages path faster too. I'll change to that. (Initially I had gone with PF_ANY because in theory, you could allocate a compound page and then break it later and free the individual pages, but I don't know if that actually happens apart from THP, and certainly doesn't look like the case for any of the stuff that we have marked as non-sensitive.) Thanks, Junaid