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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 8F217C433E0 for ; Tue, 2 Feb 2021 12:50:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5F0E864F49 for ; Tue, 2 Feb 2021 12:50:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231987AbhBBMuR (ORCPT ); Tue, 2 Feb 2021 07:50:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:50752 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231945AbhBBMuJ (ORCPT ); Tue, 2 Feb 2021 07:50:09 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4EEB964F45; Tue, 2 Feb 2021 12:49:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612270167; bh=l1mxEt58DDcLUIYn/PeqqKhgepc/YzCCfJbWYo9gF+0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m6OTQfqwmfzsDSuhaE02irM8RXZ+6I61yxWerp81AbIHaAEqJgnUU1Tago6YYG+PZ lr/J7OliC0mrwyFm+Yl+JHzEuSXK/3VdkUmPzprvLqNXJeT7c7s/R/J9ZCl2+IeFtF rRdT17MK63P20HXBjgkEetlpW86oX2ThKpxrHLgmDgGybcXOIhr5G1LeWie80VfNKg QlMcZq+bz+M1S4kZa3QSlb+JQ6x7L2zxJR92gCQJ28nKgn5G8407CWFGfDfkqlEtqc 0FuByC2cyuzV9p6QWIQuYAV6UBnFm4EyXxopzOj5OqjOkGbbBSYsX5rFiF13qam/3d 9vHDje5GpJPpg== Date: Tue, 2 Feb 2021 14:48:57 +0200 From: Mike Rapoport To: Michal Hocko Cc: James Bottomley , David Hildenbrand , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer , Palmer Dabbelt Subject: Re: [PATCH v16 07/11] secretmem: use PMD-size pages to amortize direct map fragmentation Message-ID: <20210202124857.GN242749@kernel.org> References: <20210121122723.3446-8-rppt@kernel.org> <20210126114657.GL827@dhcp22.suse.cz> <303f348d-e494-e386-d1f5-14505b5da254@redhat.com> <20210126120823.GM827@dhcp22.suse.cz> <20210128092259.GB242749@kernel.org> <73738cda43236b5ac2714e228af362b67a712f5d.camel@linux.ibm.com> <6de6b9f9c2d28eecc494e7db6ffbedc262317e11.camel@linux.ibm.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-api@vger.kernel.org On Tue, Feb 02, 2021 at 10:35:05AM +0100, Michal Hocko wrote: > On Mon 01-02-21 08:56:19, James Bottomley wrote: > > I have also proposed potential ways out of this. Either the pool is not > fixed sized and you make it a regular unevictable memory (if direct map > fragmentation is not considered a major problem) I think that the direct map fragmentation is not a major problem, and the data we have confirms it, so I'd be more than happy to entirely drop the pool, allocate memory page by page and remove each page from the direct map. Still, we cannot prove negative and it could happen that there is a workload that would suffer a lot from the direct map fragmentation, so having a pool of large pages upfront is better than trying to fix it afterwards. As we get more confidence that the direct map fragmentation is not an issue as it is common to believe we may remove the pool altogether. I think that using PMD_ORDER allocations for the pool with a fallback to order 0 will do the job, but unfortunately I doubt we'll reach a consensus about this because dogmatic beliefs are hard to shake... A more restrictive possibility is to still use plain PMD_ORDER allocations to fill the pool, without relying on CMA. In this case there will be no global secretmem specific pool to exhaust, but then it's possible to drain high order free blocks in a system, so CMA has an advantage of limiting secretmem pools to certain amount of memory with somewhat higher probability for high order allocation to succeed. > or you need a careful access control Do you mind elaborating what do you mean by "careful access control"? > or you need SIGBUS on the mmap failure (to allow at least some fallback > mode to caller). As I've already said, I agree that SIGBUS is way better than OOM at #PF time. And we can add some means to fail at mmap() time if the pools are running low. -- Sincerely yours, Mike. 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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 70CCCC433DB for ; Tue, 2 Feb 2021 12:49:31 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (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 36D1E64E7B for ; Tue, 2 Feb 2021 12:49:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36D1E64E7B 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-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id DD984100F226D; Tue, 2 Feb 2021 04:49:30 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=rppt@kernel.org; receiver= Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0211B100F2265 for ; Tue, 2 Feb 2021 04:49:27 -0800 (PST) Received: by mail.kernel.org (Postfix) with ESMTPSA id 4EEB964F45; Tue, 2 Feb 2021 12:49:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612270167; bh=l1mxEt58DDcLUIYn/PeqqKhgepc/YzCCfJbWYo9gF+0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m6OTQfqwmfzsDSuhaE02irM8RXZ+6I61yxWerp81AbIHaAEqJgnUU1Tago6YYG+PZ lr/J7OliC0mrwyFm+Yl+JHzEuSXK/3VdkUmPzprvLqNXJeT7c7s/R/J9ZCl2+IeFtF rRdT17MK63P20HXBjgkEetlpW86oX2ThKpxrHLgmDgGybcXOIhr5G1LeWie80VfNKg QlMcZq+bz+M1S4kZa3QSlb+JQ6x7L2zxJR92gCQJ28nKgn5G8407CWFGfDfkqlEtqc 0FuByC2cyuzV9p6QWIQuYAV6UBnFm4EyXxopzOj5OqjOkGbbBSYsX5rFiF13qam/3d 9vHDje5GpJPpg== Date: Tue, 2 Feb 2021 14:48:57 +0200 From: Mike Rapoport To: Michal Hocko Subject: Re: [PATCH v16 07/11] secretmem: use PMD-size pages to amortize direct map fragmentation Message-ID: <20210202124857.GN242749@kernel.org> References: <20210121122723.3446-8-rppt@kernel.org> <20210126114657.GL827@dhcp22.suse.cz> <303f348d-e494-e386-d1f5-14505b5da254@redhat.com> <20210126120823.GM827@dhcp22.suse.cz> <20210128092259.GB242749@kernel.org> <73738cda43236b5ac2714e228af362b67a712f5d.camel@linux.ibm.com> <6de6b9f9c2d28eecc494e7db6ffbedc262317e11.camel@linux.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Message-ID-Hash: XPEFKT4Y5VS6SHOOK6QD4VPRUMTX7RM6 X-Message-ID-Hash: XPEFKT4Y5VS6SHOOK6QD4VPRUMTX7RM6 X-MailFrom: rppt@kernel.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: James Bottomley , David Hildenbrand , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer , Palmer Dabbelt X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, Feb 02, 2021 at 10:35:05AM +0100, Michal Hocko wrote: > On Mon 01-02-21 08:56:19, James Bottomley wrote: > > I have also proposed potential ways out of this. Either the pool is not > fixed sized and you make it a regular unevictable memory (if direct map > fragmentation is not considered a major problem) I think that the direct map fragmentation is not a major problem, and the data we have confirms it, so I'd be more than happy to entirely drop the pool, allocate memory page by page and remove each page from the direct map. Still, we cannot prove negative and it could happen that there is a workload that would suffer a lot from the direct map fragmentation, so having a pool of large pages upfront is better than trying to fix it afterwards. As we get more confidence that the direct map fragmentation is not an issue as it is common to believe we may remove the pool altogether. I think that using PMD_ORDER allocations for the pool with a fallback to order 0 will do the job, but unfortunately I doubt we'll reach a consensus about this because dogmatic beliefs are hard to shake... A more restrictive possibility is to still use plain PMD_ORDER allocations to fill the pool, without relying on CMA. In this case there will be no global secretmem specific pool to exhaust, but then it's possible to drain high order free blocks in a system, so CMA has an advantage of limiting secretmem pools to certain amount of memory with somewhat higher probability for high order allocation to succeed. > or you need a careful access control Do you mind elaborating what do you mean by "careful access control"? > or you need SIGBUS on the mmap failure (to allow at least some fallback > mode to caller). As I've already said, I agree that SIGBUS is way better than OOM at #PF time. And we can add some means to fail at mmap() time if the pools are running low. -- Sincerely yours, Mike. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org 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.4 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 C0B0CC433E0 for ; Tue, 2 Feb 2021 12:49:41 +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 6E1FF64E7B for ; Tue, 2 Feb 2021 12:49:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E1FF64E7B 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-riscv-bounces+linux-riscv=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=UnSI+Ycvr9loeqDrqciWyobwddkVYY+nwjBl6vEJzVc=; b=C09dWErks54JX6722i5l2ClLr NHOifcPngAh81MvThCHSCu856cazsX6yURncZwIApON4hSYbbSbvtDCZjXHuqfrzTO5Bsa+3C2Ug9 oL5h3HPq6XhjycQJuLN35H2SYAg86hsqy/csHYBRg6lXXFfRVdA1aA+1Tfc5ccGazY8hQtmdmS3hx bNeVqBTSR4v1tde7UrJPu4ei/ddgipB6I79ii1Fv4dW4MmjBe5N1bL6g+r4krb8c2M+GWJ/fNhgVt it9ppy2sbrwg6IxcahZC7kGE6mYjD1MWvkOdIEkWaok5BntK52NYOxrUKiRQHm+xeTJIb+TiCdbUG FvN1CA5iA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6v7c-0003jw-RQ; Tue, 02 Feb 2021 12:49:32 +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 1l6v7Y-0003iU-Nv; Tue, 02 Feb 2021 12:49:30 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4EEB964F45; Tue, 2 Feb 2021 12:49:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612270167; bh=l1mxEt58DDcLUIYn/PeqqKhgepc/YzCCfJbWYo9gF+0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m6OTQfqwmfzsDSuhaE02irM8RXZ+6I61yxWerp81AbIHaAEqJgnUU1Tago6YYG+PZ lr/J7OliC0mrwyFm+Yl+JHzEuSXK/3VdkUmPzprvLqNXJeT7c7s/R/J9ZCl2+IeFtF rRdT17MK63P20HXBjgkEetlpW86oX2ThKpxrHLgmDgGybcXOIhr5G1LeWie80VfNKg QlMcZq+bz+M1S4kZa3QSlb+JQ6x7L2zxJR92gCQJ28nKgn5G8407CWFGfDfkqlEtqc 0FuByC2cyuzV9p6QWIQuYAV6UBnFm4EyXxopzOj5OqjOkGbbBSYsX5rFiF13qam/3d 9vHDje5GpJPpg== Date: Tue, 2 Feb 2021 14:48:57 +0200 From: Mike Rapoport To: Michal Hocko Subject: Re: [PATCH v16 07/11] secretmem: use PMD-size pages to amortize direct map fragmentation Message-ID: <20210202124857.GN242749@kernel.org> References: <20210121122723.3446-8-rppt@kernel.org> <20210126114657.GL827@dhcp22.suse.cz> <303f348d-e494-e386-d1f5-14505b5da254@redhat.com> <20210126120823.GM827@dhcp22.suse.cz> <20210128092259.GB242749@kernel.org> <73738cda43236b5ac2714e228af362b67a712f5d.camel@linux.ibm.com> <6de6b9f9c2d28eecc494e7db6ffbedc262317e11.camel@linux.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210202_074928_993760_5CE88225 X-CRM114-Status: GOOD ( 18.21 ) X-BeenThere: linux-riscv@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 , Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Shuah Khan , Thomas Gleixner , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Palmer Dabbelt , Arnd Bergmann , James Bottomley , Hagen Paul Pfeifer , 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, Shakeel Butt , Andrew Morton , Rick Edgecombe , Roman Gushchin Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, Feb 02, 2021 at 10:35:05AM +0100, Michal Hocko wrote: > On Mon 01-02-21 08:56:19, James Bottomley wrote: > > I have also proposed potential ways out of this. Either the pool is not > fixed sized and you make it a regular unevictable memory (if direct map > fragmentation is not considered a major problem) I think that the direct map fragmentation is not a major problem, and the data we have confirms it, so I'd be more than happy to entirely drop the pool, allocate memory page by page and remove each page from the direct map. Still, we cannot prove negative and it could happen that there is a workload that would suffer a lot from the direct map fragmentation, so having a pool of large pages upfront is better than trying to fix it afterwards. As we get more confidence that the direct map fragmentation is not an issue as it is common to believe we may remove the pool altogether. I think that using PMD_ORDER allocations for the pool with a fallback to order 0 will do the job, but unfortunately I doubt we'll reach a consensus about this because dogmatic beliefs are hard to shake... A more restrictive possibility is to still use plain PMD_ORDER allocations to fill the pool, without relying on CMA. In this case there will be no global secretmem specific pool to exhaust, but then it's possible to drain high order free blocks in a system, so CMA has an advantage of limiting secretmem pools to certain amount of memory with somewhat higher probability for high order allocation to succeed. > or you need a careful access control Do you mind elaborating what do you mean by "careful access control"? > or you need SIGBUS on the mmap failure (to allow at least some fallback > mode to caller). As I've already said, I agree that SIGBUS is way better than OOM at #PF time. And we can add some means to fail at mmap() time if the pools are running low. -- Sincerely yours, Mike. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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.4 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 5CA02C433E6 for ; Tue, 2 Feb 2021 12:50:44 +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 0BC1264E7B for ; Tue, 2 Feb 2021 12:50:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0BC1264E7B 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=nTKEFi+oxh9YPfazi4bSX+d7uTrKWHQsYlooUNw+EYs=; b=PsxeXYxal8jjXDXihlFMX4GVb b2T3ggis2wJetrFdeWzzDhohyEed/JWMgcmZvUJDxu9D5Y1mkj/8+InMMooJenvJ/1VAp9XDTQp01 pB0oR19vqYEQEDUUBreE6nlBS1kX23/4JCrf0meO5bYp95VbylQ4QqxQK6vlQFTbiC1m8FTfG6bZc 2jv4FYf/ogFrI1iZ4xdkImQ1F0yi1Vz1/zn5ScRXn/9W1iYzOCcvaB5mgKC/E1foG1oYFPTBANAbR zn7fmgZxaa7Xx9cfvH5vM6aYoeQ0S+FQjuoEPubUj55T1Umi0OK+/32fgW0gn6IiV7nqf/bg0A6WI 1jGos8HFg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6v7b-0003jg-Be; Tue, 02 Feb 2021 12:49:31 +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 1l6v7Y-0003iU-Nv; Tue, 02 Feb 2021 12:49:30 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4EEB964F45; Tue, 2 Feb 2021 12:49:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612270167; bh=l1mxEt58DDcLUIYn/PeqqKhgepc/YzCCfJbWYo9gF+0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m6OTQfqwmfzsDSuhaE02irM8RXZ+6I61yxWerp81AbIHaAEqJgnUU1Tago6YYG+PZ lr/J7OliC0mrwyFm+Yl+JHzEuSXK/3VdkUmPzprvLqNXJeT7c7s/R/J9ZCl2+IeFtF rRdT17MK63P20HXBjgkEetlpW86oX2ThKpxrHLgmDgGybcXOIhr5G1LeWie80VfNKg QlMcZq+bz+M1S4kZa3QSlb+JQ6x7L2zxJR92gCQJ28nKgn5G8407CWFGfDfkqlEtqc 0FuByC2cyuzV9p6QWIQuYAV6UBnFm4EyXxopzOj5OqjOkGbbBSYsX5rFiF13qam/3d 9vHDje5GpJPpg== Date: Tue, 2 Feb 2021 14:48:57 +0200 From: Mike Rapoport To: Michal Hocko Subject: Re: [PATCH v16 07/11] secretmem: use PMD-size pages to amortize direct map fragmentation Message-ID: <20210202124857.GN242749@kernel.org> References: <20210121122723.3446-8-rppt@kernel.org> <20210126114657.GL827@dhcp22.suse.cz> <303f348d-e494-e386-d1f5-14505b5da254@redhat.com> <20210126120823.GM827@dhcp22.suse.cz> <20210128092259.GB242749@kernel.org> <73738cda43236b5ac2714e228af362b67a712f5d.camel@linux.ibm.com> <6de6b9f9c2d28eecc494e7db6ffbedc262317e11.camel@linux.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210202_074928_993760_5CE88225 X-CRM114-Status: GOOD ( 18.21 ) 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 , Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Shuah Khan , Thomas Gleixner , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Palmer Dabbelt , Arnd Bergmann , James Bottomley , Hagen Paul Pfeifer , 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, Shakeel Butt , Andrew Morton , Rick Edgecombe , Roman Gushchin 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 Tue, Feb 02, 2021 at 10:35:05AM +0100, Michal Hocko wrote: > On Mon 01-02-21 08:56:19, James Bottomley wrote: > > I have also proposed potential ways out of this. Either the pool is not > fixed sized and you make it a regular unevictable memory (if direct map > fragmentation is not considered a major problem) I think that the direct map fragmentation is not a major problem, and the data we have confirms it, so I'd be more than happy to entirely drop the pool, allocate memory page by page and remove each page from the direct map. Still, we cannot prove negative and it could happen that there is a workload that would suffer a lot from the direct map fragmentation, so having a pool of large pages upfront is better than trying to fix it afterwards. As we get more confidence that the direct map fragmentation is not an issue as it is common to believe we may remove the pool altogether. I think that using PMD_ORDER allocations for the pool with a fallback to order 0 will do the job, but unfortunately I doubt we'll reach a consensus about this because dogmatic beliefs are hard to shake... A more restrictive possibility is to still use plain PMD_ORDER allocations to fill the pool, without relying on CMA. In this case there will be no global secretmem specific pool to exhaust, but then it's possible to drain high order free blocks in a system, so CMA has an advantage of limiting secretmem pools to certain amount of memory with somewhat higher probability for high order allocation to succeed. > or you need a careful access control Do you mind elaborating what do you mean by "careful access control"? > or you need SIGBUS on the mmap failure (to allow at least some fallback > mode to caller). As I've already said, I agree that SIGBUS is way better than OOM at #PF time. And we can add some means to fail at mmap() time if the pools are running low. -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel