Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp425615pxb; Thu, 19 Aug 2021 02:56:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyfnT7JGXz36f66xAaDuY2Qdo8srNGqS/lzk3KIP3aJa39ienMBwQyKQIJXraVMBbrXiJtp X-Received: by 2002:a05:6402:518f:: with SMTP id q15mr15346826edd.226.1629367013444; Thu, 19 Aug 2021 02:56:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629367013; cv=none; d=google.com; s=arc-20160816; b=oDFkzMS+m5hgGDc6AntIrdv7zCyUqWZbnW7iUJzgdTCAukFUCGK7TfR/XUh2rHLCwR QbGQGPLZtsW6BOHVipq8yr/oljGd/Ypz3N85mNhAZkF0ghmRzMtVhVCBQKL6L6CVENyT EomOnpCggV5lK0q3EGfWxhtFDWexHG8r/U47ztMJ8T1nYPBHua4Z2SUoqx9yQ+ejSu1o xjxEnf3hO6m4VKXCorV3tRr/ybo7O2TuCruTtismWeTBZCE+l4oYukFjqDLHCfM1f/uE dkRzNgk8Gxd9N93c0AlIEEvdJffTS6IRS3LRzF299I0rCJD9QguVlOEPqpAegn1uu7V1 13Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=pBx7UvjXszKNzjrsiqHLkrPggQDMMUiJVYYt4I/aFBY=; b=tuSfvM3lVDzNix2WeZ4jaTmJ1h181jEf0Ozu4VRbFmj3e4efllzlnAPvvFfIcUmcho sbe62yGl7UqVpPaBBHI4fpXZdSvpjI8hteeSyfLn0fdMS8QF765mZevP0HKrsymTgYDv EQG990AZjoVRoJRRQV4XPrYvgfBsbtu5S4+0qcKwGe5oIr7kd2o5LBKOZv2j2vvMl5AR owB63K+d712AmCljFofnhnpSQHr6y9SSmHmFpzNAgwvYrCnl8jW/NYJCAlRz//8bAGSD ZAY682VxLkbZGPTkOCDYli48iwSa0FxF8XgBAettlUzDAoQQXWkAdtNpg1L/0pf/s2lZ N93w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Gb3P5uQs; dkim=neutral (no key) header.i=@suse.de header.b=ZTvPUcKZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j3si2915037edp.549.2021.08.19.02.56.30; Thu, 19 Aug 2021 02:56:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=Gb3P5uQs; dkim=neutral (no key) header.i=@suse.de header.b=ZTvPUcKZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237834AbhHSJzs (ORCPT + 99 others); Thu, 19 Aug 2021 05:55:48 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:39682 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229745AbhHSJzr (ORCPT ); Thu, 19 Aug 2021 05:55:47 -0400 Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 3A63E200B8; Thu, 19 Aug 2021 09:55:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1629366910; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pBx7UvjXszKNzjrsiqHLkrPggQDMMUiJVYYt4I/aFBY=; b=Gb3P5uQsliDPSyaSdPwt9DDA/+NZsn8pb8lq88jTIZv9/3O282MkGBKjMJd02MfQAmRiux 80YRH5jd6dF9pnmUxVfjcUCM9qYttgOcCAPatQS1HNpTDeChF5LVaQitWdRtlPCjp6h+e5 GG1YL5EYBriHTJE6nc5LgGgpfQypIlw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1629366910; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pBx7UvjXszKNzjrsiqHLkrPggQDMMUiJVYYt4I/aFBY=; b=ZTvPUcKZrNXECsQm0diB42W33txsl3l+81DrtzSPnII0dabhm0Flu3KcbMI2L+aqhwYkvs c7v2zmNCoxx6QICg== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id 6602F1389C; Thu, 19 Aug 2021 09:55:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id iY8kF30qHmGZNAAAGKfGzw (envelope-from ); Thu, 19 Aug 2021 09:55:09 +0000 Date: Thu, 19 Aug 2021 11:55:07 +0200 From: Joerg Roedel To: David Hildenbrand Cc: Dave Hansen , Andi Kleen , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: Re: [PATCH 1/5] mm: Add support for unaccepted memory Message-ID: References: <9748c07c-4e59-89d0-f425-c57f778d1b42@linux.intel.com> <17b6a3a3-bd7d-f57e-8762-96258b16247a@intel.com> <796a4b20-7fa3-3086-efa0-2f728f35ae06@linux.intel.com> <3caf5e73-c104-0057-680c-7851476e67ac@linux.intel.com> <25312492-5d67-e5b0-1a51-b6880f45a550@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On Tue, Aug 17, 2021 at 05:00:55PM +0200, David Hildenbrand wrote: > Not sure if already discussed, but what about making sure that free pages > are not a mixture (partially unaccepted, partially accepted). > > You'd have to expose the pages in that granularity to the buddy > (__free_pages_core), indicating the state. You'd have to reject merging > pages of differing acceptance state. > > Accepting a page would then be handled outside of the zone lock, completely > controlled by the state. > > So a page in the buddy would either be completely accepted or completely > unaccepted, signaled e.g., by PageOffline(). > > Consequently, when allocating a 4KiB page, you'd split an unaccepted 2MiB > page into separate unaccepted pages. You'd grab one of the unaccepted 4KiB > pages and accept it before initializing it and handing it out. Yes, that is the alternative to over-accepting memory on allocation. But the problem here is that accepting/validating memory is an expensive operation which also requires a hypercall. The hypercalls on SNP and TDX can accept/validate multiple pages in one call. So the recommendation is to accept memory in bigger chunks, like the 2MB that have been proposed. Only accepting memory in allocation size might be too slow, as there is a lot of code doing order-0 allocations. I think this approach will also be more intrusive to the page alloctor, as it needs more changes on the free path to check for acceptance states before pages can be merged. Regards, Joerg