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=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 76350C388F7 for ; Tue, 10 Nov 2020 18:07:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2B17B20809 for ; Tue, 10 Nov 2020 18:07:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="rsCfawPZ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730871AbgKJSHE (ORCPT ); Tue, 10 Nov 2020 13:07:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:56100 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726428AbgKJSHD (ORCPT ); Tue, 10 Nov 2020 13:07:03 -0500 Received: from kernel.org (unknown [77.125.7.142]) (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 C35F820781; Tue, 10 Nov 2020 18:06:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605031623; bh=bAkJ6qFghBqAmYDEu7geL4WoAC5U+zvSUa3tfgn5GqA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rsCfawPZ7PZXYREKxvAae+uk/8IQqHbGnFjdff7AGzyGjc4x/SKxcILYVT/rLCce9 nmpcocs0Se3KfPVLk80KrhXz6x5Oy3hYomKMAGm/YGBiEJSxYFnSu9uNQghCJwavMR lgeiRSDZJxGsficIgAw5m1qVpszWlc3MZZCq7S1w= Date: Tue, 10 Nov 2020 20:06:48 +0200 From: Mike Rapoport To: David Hildenbrand Cc: 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 , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , 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 Subject: Re: [PATCH v8 2/9] mmap: make mlock_future_check() global Message-ID: <20201110180648.GB4758@kernel.org> References: <20201110151444.20662-1-rppt@kernel.org> <20201110151444.20662-3-rppt@kernel.org> <9e2fafd7-abb0-aa79-fa66-cd8662307446@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e2fafd7-abb0-aa79-fa66-cd8662307446@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Tue, Nov 10, 2020 at 06:17:26PM +0100, David Hildenbrand wrote: > On 10.11.20 16:14, Mike Rapoport wrote: > > From: Mike Rapoport > > > > It will be used by the upcoming secret memory implementation. > > > > Signed-off-by: Mike Rapoport > > --- > > mm/internal.h | 3 +++ > > mm/mmap.c | 5 ++--- > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/mm/internal.h b/mm/internal.h > > index c43ccdddb0f6..ae146a260b14 100644 > > --- a/mm/internal.h > > +++ b/mm/internal.h > > @@ -348,6 +348,9 @@ static inline void munlock_vma_pages_all(struct vm_area_struct *vma) > > extern void mlock_vma_page(struct page *page); > > extern unsigned int munlock_vma_page(struct page *page); > > +extern int mlock_future_check(struct mm_struct *mm, unsigned long flags, > > + unsigned long len); > > + > > /* > > * Clear the page's PageMlocked(). This can be useful in a situation where > > * we want to unconditionally remove a page from the pagecache -- e.g., > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 61f72b09d990..c481f088bd50 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1348,9 +1348,8 @@ static inline unsigned long round_hint_to_min(unsigned long hint) > > return hint; > > } > > -static inline int mlock_future_check(struct mm_struct *mm, > > - unsigned long flags, > > - unsigned long len) > > +int mlock_future_check(struct mm_struct *mm, unsigned long flags, > > + unsigned long len) > > { > > unsigned long locked, lock_limit; > > > > So, an interesting question is if you actually want to charge secretmem > pages against mlock now, or if you want a dedicated secretmem cgroup > controller instead? Well, with the current implementation there are three limits an administrator can use to control secretmem limits: mlock, memcg and kernel parameter. The kernel parameter puts a global upper limit for secretmem usage, memcg accounts all secretmem allocations, including the unused memory in large pages caching and mlock allows per task limit for secretmem mappings, well, like mlock does. I didn't consider a dedicated cgroup, as it seems we already have enough existing knobs and a new one would be unnecessary. > -- > Thanks, > > David / dhildenb > -- 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=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 EE8C2C4741F for ; Tue, 10 Nov 2020 18:07:07 +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 6C31821D93 for ; Tue, 10 Nov 2020 18:07:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="rsCfawPZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6C31821D93 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 ED327166F4B67; Tue, 10 Nov 2020 10:07:06 -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 58533166F4B65 for ; Tue, 10 Nov 2020 10:07:04 -0800 (PST) Received: from kernel.org (unknown [77.125.7.142]) (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 C35F820781; Tue, 10 Nov 2020 18:06:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605031623; bh=bAkJ6qFghBqAmYDEu7geL4WoAC5U+zvSUa3tfgn5GqA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rsCfawPZ7PZXYREKxvAae+uk/8IQqHbGnFjdff7AGzyGjc4x/SKxcILYVT/rLCce9 nmpcocs0Se3KfPVLk80KrhXz6x5Oy3hYomKMAGm/YGBiEJSxYFnSu9uNQghCJwavMR lgeiRSDZJxGsficIgAw5m1qVpszWlc3MZZCq7S1w= Date: Tue, 10 Nov 2020 20:06:48 +0200 From: Mike Rapoport To: David Hildenbrand Subject: Re: [PATCH v8 2/9] mmap: make mlock_future_check() global Message-ID: <20201110180648.GB4758@kernel.org> References: <20201110151444.20662-1-rppt@kernel.org> <20201110151444.20662-3-rppt@kernel.org> <9e2fafd7-abb0-aa79-fa66-cd8662307446@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9e2fafd7-abb0-aa79-fa66-cd8662307446@redhat.com> Message-ID-Hash: D5H75DZO3EXTOEUTUZJQRCPPLRBWSE56 X-Message-ID-Hash: D5H75DZO3EXTOEUTUZJQRCPPLRBWSE56 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: Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Mike Rapoport , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , linux-api@vger.kernel.org, linux-arch@vger.ker nel.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 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, Nov 10, 2020 at 06:17:26PM +0100, David Hildenbrand wrote: > On 10.11.20 16:14, Mike Rapoport wrote: > > From: Mike Rapoport > > > > It will be used by the upcoming secret memory implementation. > > > > Signed-off-by: Mike Rapoport > > --- > > mm/internal.h | 3 +++ > > mm/mmap.c | 5 ++--- > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/mm/internal.h b/mm/internal.h > > index c43ccdddb0f6..ae146a260b14 100644 > > --- a/mm/internal.h > > +++ b/mm/internal.h > > @@ -348,6 +348,9 @@ static inline void munlock_vma_pages_all(struct vm_area_struct *vma) > > extern void mlock_vma_page(struct page *page); > > extern unsigned int munlock_vma_page(struct page *page); > > +extern int mlock_future_check(struct mm_struct *mm, unsigned long flags, > > + unsigned long len); > > + > > /* > > * Clear the page's PageMlocked(). This can be useful in a situation where > > * we want to unconditionally remove a page from the pagecache -- e.g., > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 61f72b09d990..c481f088bd50 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1348,9 +1348,8 @@ static inline unsigned long round_hint_to_min(unsigned long hint) > > return hint; > > } > > -static inline int mlock_future_check(struct mm_struct *mm, > > - unsigned long flags, > > - unsigned long len) > > +int mlock_future_check(struct mm_struct *mm, unsigned long flags, > > + unsigned long len) > > { > > unsigned long locked, lock_limit; > > > > So, an interesting question is if you actually want to charge secretmem > pages against mlock now, or if you want a dedicated secretmem cgroup > controller instead? Well, with the current implementation there are three limits an administrator can use to control secretmem limits: mlock, memcg and kernel parameter. The kernel parameter puts a global upper limit for secretmem usage, memcg accounts all secretmem allocations, including the unused memory in large pages caching and mlock allows per task limit for secretmem mappings, well, like mlock does. I didn't consider a dedicated cgroup, as it seems we already have enough existing knobs and a new one would be unnecessary. > -- > Thanks, > > David / dhildenb > -- 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=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 D704AC388F7 for ; Tue, 10 Nov 2020 18:07:25 +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 6547F20781 for ; Tue, 10 Nov 2020 18:07:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="r6t7YOx2"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="rsCfawPZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6547F20781 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=kASXSdAsmqUTpoxYa6YDsqs5BfcACJPpX3VaUGfIH5o=; b=r6t7YOx2AH7UlXnMJTA2E9CpI nxhzVWVvtbAt+kUyEsV4G3O7NHt8/dn3uTOEwpXtTHcY++BuPb9Ltf4yb2yXqFj38WC6xbhpXVRTd OhDTqGfzqgNFvMBWgJ1vWmZrKa9Py99Lh+R4fL1CEJ0fRalsBgsT6ekpJvCSv2DD13ygrOzP5whuL xQRhpDro9bFiQt4PQkKkIttZzS5kF6yxwLz+9Uu8lCxsj1E2joJkCkYisliIedzdI6j2uZAoldp79 1IyWcc5f9AiJXc3jT7oY8Au+d62qC8kRiioBDQEjcXfgTjnjUPnrOnjzXHmFW1x4aRJgX+A2ybQxn D+3n6ne0A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcY2v-000879-8H; Tue, 10 Nov 2020 18:07:09 +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 1kcY2q-00084z-EC; Tue, 10 Nov 2020 18:07:05 +0000 Received: from kernel.org (unknown [77.125.7.142]) (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 C35F820781; Tue, 10 Nov 2020 18:06:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605031623; bh=bAkJ6qFghBqAmYDEu7geL4WoAC5U+zvSUa3tfgn5GqA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rsCfawPZ7PZXYREKxvAae+uk/8IQqHbGnFjdff7AGzyGjc4x/SKxcILYVT/rLCce9 nmpcocs0Se3KfPVLk80KrhXz6x5Oy3hYomKMAGm/YGBiEJSxYFnSu9uNQghCJwavMR lgeiRSDZJxGsficIgAw5m1qVpszWlc3MZZCq7S1w= Date: Tue, 10 Nov 2020 20:06:48 +0200 From: Mike Rapoport To: David Hildenbrand Subject: Re: [PATCH v8 2/9] mmap: make mlock_future_check() global Message-ID: <20201110180648.GB4758@kernel.org> References: <20201110151444.20662-1-rppt@kernel.org> <20201110151444.20662-3-rppt@kernel.org> <9e2fafd7-abb0-aa79-fa66-cd8662307446@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9e2fafd7-abb0-aa79-fa66-cd8662307446@redhat.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201110_130704_728345_E9388918 X-CRM114-Status: GOOD ( 26.32 ) 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 , 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 , 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 , Rick Edgecombe 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, Nov 10, 2020 at 06:17:26PM +0100, David Hildenbrand wrote: > On 10.11.20 16:14, Mike Rapoport wrote: > > From: Mike Rapoport > > > > It will be used by the upcoming secret memory implementation. > > > > Signed-off-by: Mike Rapoport > > --- > > mm/internal.h | 3 +++ > > mm/mmap.c | 5 ++--- > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/mm/internal.h b/mm/internal.h > > index c43ccdddb0f6..ae146a260b14 100644 > > --- a/mm/internal.h > > +++ b/mm/internal.h > > @@ -348,6 +348,9 @@ static inline void munlock_vma_pages_all(struct vm_area_struct *vma) > > extern void mlock_vma_page(struct page *page); > > extern unsigned int munlock_vma_page(struct page *page); > > +extern int mlock_future_check(struct mm_struct *mm, unsigned long flags, > > + unsigned long len); > > + > > /* > > * Clear the page's PageMlocked(). This can be useful in a situation where > > * we want to unconditionally remove a page from the pagecache -- e.g., > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 61f72b09d990..c481f088bd50 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1348,9 +1348,8 @@ static inline unsigned long round_hint_to_min(unsigned long hint) > > return hint; > > } > > -static inline int mlock_future_check(struct mm_struct *mm, > > - unsigned long flags, > > - unsigned long len) > > +int mlock_future_check(struct mm_struct *mm, unsigned long flags, > > + unsigned long len) > > { > > unsigned long locked, lock_limit; > > > > So, an interesting question is if you actually want to charge secretmem > pages against mlock now, or if you want a dedicated secretmem cgroup > controller instead? Well, with the current implementation there are three limits an administrator can use to control secretmem limits: mlock, memcg and kernel parameter. The kernel parameter puts a global upper limit for secretmem usage, memcg accounts all secretmem allocations, including the unused memory in large pages caching and mlock allows per task limit for secretmem mappings, well, like mlock does. I didn't consider a dedicated cgroup, as it seems we already have enough existing knobs and a new one would be unnecessary. > -- > Thanks, > > David / dhildenb > -- 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=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 D6213C388F7 for ; Tue, 10 Nov 2020 18:08: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 4722820781 for ; Tue, 10 Nov 2020 18:08:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1wZsTk0L"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="rsCfawPZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4722820781 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=BH+mfXLSxMqTRMeA2eH1Vcg+Z6SDE6eLUD0eM+jH5Zo=; b=1wZsTk0LWiQVJWOQBFQOIIDBG TpwkRWIRMX6q9wD+OGm9OuMfGJGZv0HMf76CU9HCc0ThmVUeXUgn0MEMlOeweyNG4iQc4aPdLKM8/ rsmjz7Tl0uFKzUFkvw1eTpx91tvyXoNTnKaA2xbmHYzz6jQ0xteDPiVIGrEbvkoXl94MbXjXkjH2G 1vR8s72wh431HqoxuyFWIxzo1jZmWM8ZjsdXv44ROkUmqP9YWUGfrDOXRWTjOuZdGIZIltcZDuNUM xQQSL/o4/IRTB/++ZEWLVx+9w/+L4pib58zakkDjfkTJGiziCKwRVJMZ+jXYcD9fB5oagU8VIwyaA nt91PWs1w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kcY2t-00086R-75; Tue, 10 Nov 2020 18:07:07 +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 1kcY2q-00084z-EC; Tue, 10 Nov 2020 18:07:05 +0000 Received: from kernel.org (unknown [77.125.7.142]) (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 C35F820781; Tue, 10 Nov 2020 18:06:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605031623; bh=bAkJ6qFghBqAmYDEu7geL4WoAC5U+zvSUa3tfgn5GqA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rsCfawPZ7PZXYREKxvAae+uk/8IQqHbGnFjdff7AGzyGjc4x/SKxcILYVT/rLCce9 nmpcocs0Se3KfPVLk80KrhXz6x5Oy3hYomKMAGm/YGBiEJSxYFnSu9uNQghCJwavMR lgeiRSDZJxGsficIgAw5m1qVpszWlc3MZZCq7S1w= Date: Tue, 10 Nov 2020 20:06:48 +0200 From: Mike Rapoport To: David Hildenbrand Subject: Re: [PATCH v8 2/9] mmap: make mlock_future_check() global Message-ID: <20201110180648.GB4758@kernel.org> References: <20201110151444.20662-1-rppt@kernel.org> <20201110151444.20662-3-rppt@kernel.org> <9e2fafd7-abb0-aa79-fa66-cd8662307446@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9e2fafd7-abb0-aa79-fa66-cd8662307446@redhat.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201110_130704_728345_E9388918 X-CRM114-Status: GOOD ( 26.32 ) 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 , 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 , 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 , Rick Edgecombe 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, Nov 10, 2020 at 06:17:26PM +0100, David Hildenbrand wrote: > On 10.11.20 16:14, Mike Rapoport wrote: > > From: Mike Rapoport > > > > It will be used by the upcoming secret memory implementation. > > > > Signed-off-by: Mike Rapoport > > --- > > mm/internal.h | 3 +++ > > mm/mmap.c | 5 ++--- > > 2 files changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/mm/internal.h b/mm/internal.h > > index c43ccdddb0f6..ae146a260b14 100644 > > --- a/mm/internal.h > > +++ b/mm/internal.h > > @@ -348,6 +348,9 @@ static inline void munlock_vma_pages_all(struct vm_area_struct *vma) > > extern void mlock_vma_page(struct page *page); > > extern unsigned int munlock_vma_page(struct page *page); > > +extern int mlock_future_check(struct mm_struct *mm, unsigned long flags, > > + unsigned long len); > > + > > /* > > * Clear the page's PageMlocked(). This can be useful in a situation where > > * we want to unconditionally remove a page from the pagecache -- e.g., > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 61f72b09d990..c481f088bd50 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1348,9 +1348,8 @@ static inline unsigned long round_hint_to_min(unsigned long hint) > > return hint; > > } > > -static inline int mlock_future_check(struct mm_struct *mm, > > - unsigned long flags, > > - unsigned long len) > > +int mlock_future_check(struct mm_struct *mm, unsigned long flags, > > + unsigned long len) > > { > > unsigned long locked, lock_limit; > > > > So, an interesting question is if you actually want to charge secretmem > pages against mlock now, or if you want a dedicated secretmem cgroup > controller instead? Well, with the current implementation there are three limits an administrator can use to control secretmem limits: mlock, memcg and kernel parameter. The kernel parameter puts a global upper limit for secretmem usage, memcg accounts all secretmem allocations, including the unused memory in large pages caching and mlock allows per task limit for secretmem mappings, well, like mlock does. I didn't consider a dedicated cgroup, as it seems we already have enough existing knobs and a new one would be unnecessary. > -- > Thanks, > > David / dhildenb > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel