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=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 7944CC4727C for ; Tue, 29 Sep 2020 13:07:20 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F1DAC20848 for ; Tue, 29 Sep 2020 13:07:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SJurc+Hd"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="YfoO9Oo/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1DAC20848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=l0HLf/7OykQwqr6v9CnbUKYlJO4huRPKWGVO98K3XlU=; b=SJurc+HdICrRdmM1N66x9oUDy PbXTgfPCrLlQEb1WSB0LkGIFyKxNd2g/IVa0FEHUDDrmY4pvcxI/RDHuQBWuNqxBdLhIyHZWak1tj QTk9nnE5z0KkZTx8dE1DahJFwgo75h9+3D6rGNZmiJ0oaVYZa5/x6tSKRsDJGA/YvcIBGrnYvz6/0 zt/lusAiGSFLqhLhvkgAOfV2tBzMPQNjo5XLf7gGJIGtLof9b5Gdf2AhMT4V56ueljaPZfDy78rfO yU+jY2QMPSc3bu5lLeFeqolGhfIelhSa2GTFo+h956oIjRoM9TWz/SkwdCsdVDXWhGIe3OfLntReV lq2Vlboig==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNFKK-00037K-2r; Tue, 29 Sep 2020 13:05:52 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNFKG-00035G-7W; Tue, 29 Sep 2020 13:05:49 +0000 Received: from kernel.org (unknown [87.71.73.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4CD4820848; Tue, 29 Sep 2020 13:05:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601384746; bh=w8jEjdPVhwgAP8ieOGmZq7rvrkzmFW13pl6Bcj/9DDg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YfoO9Oo/YwKl80W7Ps/3xh0cfYEHin8QOUrn/iFqhLYw+b2DAWHKu9Y+mnqgIAACA uQkYtRdB+liRGsxjQlUpAtvTPmGTHbQnf35XbZMDwXCeXkiEteBW7/GT/3ZbUZnHCL kuQnBbyQK81Mz6jqRSLbGj/2AcjW0JSpMYmSqJQw= Date: Tue, 29 Sep 2020 16:05:29 +0300 From: Mike Rapoport To: Peter Zijlstra Subject: Re: [PATCH v6 5/6] mm: secretmem: use PMD-size pages to amortize direct map fragmentation Message-ID: <20200929130529.GE2142832@kernel.org> References: <20200924132904.1391-1-rppt@kernel.org> <20200924132904.1391-6-rppt@kernel.org> <20200925074125.GQ2628@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200925074125.GQ2628@hirez.programming.kicks-ass.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200929_090548_773724_1AF76047 X-CRM114-Status: GOOD ( 26.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , David Hildenbrand , Catalin Marinas , Dave Hansen , linux-mm@kvack.org, Will Deacon , linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Idan Yaniv , Thomas Gleixner , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Shuah Khan , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Arnd Bergmann , James Bottomley , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Dan Williams , linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Palmer Dabbelt , linux-fsdevel@vger.kernel.org, Andrew Morton Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Sep 25, 2020 at 09:41:25AM +0200, Peter Zijlstra wrote: > On Thu, Sep 24, 2020 at 04:29:03PM +0300, Mike Rapoport wrote: > > From: Mike Rapoport > > > > Removing a PAGE_SIZE page from the direct map every time such page is > > allocated for a secret memory mapping will cause severe fragmentation of > > the direct map. This fragmentation can be reduced by using PMD-size pages > > as a pool for small pages for secret memory mappings. > > > > Add a gen_pool per secretmem inode and lazily populate this pool with > > PMD-size pages. > > What's the actual efficacy of this? Since the pmd is per inode, all I > need is a lot of inodes and we're in business to destroy the directmap, > no? > > Afaict there's no privs needed to use this, all a process needs is to > stay below the mlock limit, so a 'fork-bomb' that maps a single secret > page will utterly destroy the direct map. This indeed will cause 1G pages in the direct map to be split into 2M chunks, but I disagree with 'destroy' term here. Citing the cover letter of an earlier version of this series: I've tried to find some numbers that show the benefit of using larger pages in the direct map, but I couldn't find anything so I've run a couple of benchmarks from phoronix-test-suite on my laptop (i7-8650U with 32G RAM). I've tested three variants: the default with 28G of the physical memory covered with 1G pages, then I disabled 1G pages using "nogbpages" in the kernel command line and at last I've forced the entire direct map to use 4K pages using a simple patch to arch/x86/mm/init.c. I've made runs of the benchmarks with SSD and tmpfs. Surprisingly, the results does not show huge advantage for large pages. For instance, here the results for kernel build with 'make -j8', in seconds: | 1G | 2M | 4K ----------------------+--------+--------+--------- ssd, mitigations=on | 308.75 | 317.37 | 314.9 ssd, mitigations=off | 305.25 | 295.32 | 304.92 ram, mitigations=on | 301.58 | 322.49 | 306.54 ram, mitigations=off | 299.32 | 288.44 | 310.65 All the results I have are available here: https://docs.google.com/spreadsheets/d/1tdD-cu8e93vnfGsTFxZ5YdaEfs2E1GELlvWNOGkJV2U/edit?usp=sharing The numbers suggest that using smaller pages in the direct map does not necessarily leads to performance degradation and some runs produced better results with smaller pages in the direct map. > I really don't like this, at all. > > IIRC Kirill looked at merging the directmap. I think he ran into > performance issues there, but we really need something like that before > something like this lands. -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel