From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlastimil Babka Subject: Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls Date: Wed, 22 Jul 2015 11:16:10 +0200 Message-ID: <55AF5F5A.3000707@suse.cz> References: <1437508781-28655-1-git-send-email-emunson@akamai.com> <1437508781-28655-3-git-send-email-emunson@akamai.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1437508781-28655-3-git-send-email-emunson@akamai.com> Sender: linux-m68k-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Eric B Munson , Andrew Morton Cc: Michal Hocko , Heiko Carstens , Geert Uytterhoeven , Catalin Marinas , Stephen Rothwell , Guenter Roeck , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, linux-cris-kernel@axis.com, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@linux-mips.org, linux-am33-list@redhat.com, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org On 07/21/2015 09:59 PM, Eric B Munson wrote: > With the refactored mlock code, introduce new system calls for mlock, > munlock, and munlockall. The new calls will allow the user to specify > what lock states are being added or cleared. mlock2 and munlock2 are > trivial at the moment, but a follow on patch will add a new mlock state > making them useful. > > munlock2 addresses a limitation of the current implementation. If a ^ munlockall2? > user calls mlockall(MCL_CURRENT | MCL_FUTURE) and then later decides > that MCL_FUTURE should be removed, they would have to call munlockall() > followed by mlockall(MCL_CURRENT) which could potentially be very > expensive. The new munlockall2 system call allows a user to simply > clear the MCL_FUTURE flag. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlastimil Babka Date: Wed, 22 Jul 2015 09:16:10 +0000 Subject: Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls Message-Id: <55AF5F5A.3000707@suse.cz> List-Id: References: <1437508781-28655-1-git-send-email-emunson@akamai.com> <1437508781-28655-3-git-send-email-emunson@akamai.com> In-Reply-To: <1437508781-28655-3-git-send-email-emunson@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Eric B Munson , Andrew Morton Cc: Michal Hocko , Heiko Carstens , Geert Uytterhoeven , Catalin Marinas , Stephen Rothwell , Guenter Roeck , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, linux-cris-kernel@axis.com, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@linux-mips.org, linux-am33-list@redhat.com, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org On 07/21/2015 09:59 PM, Eric B Munson wrote: > With the refactored mlock code, introduce new system calls for mlock, > munlock, and munlockall. The new calls will allow the user to specify > what lock states are being added or cleared. mlock2 and munlock2 are > trivial at the moment, but a follow on patch will add a new mlock state > making them useful. > > munlock2 addresses a limitation of the current implementation. If a ^ munlockall2? > user calls mlockall(MCL_CURRENT | MCL_FUTURE) and then later decides > that MCL_FUTURE should be removed, they would have to call munlockall() > followed by mlockall(MCL_CURRENT) which could potentially be very > expensive. The new munlockall2 system call allows a user to simply > clear the MCL_FUTURE flag. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: vbabka@suse.cz (Vlastimil Babka) Date: Wed, 22 Jul 2015 11:16:10 +0200 Subject: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls In-Reply-To: <1437508781-28655-3-git-send-email-emunson@akamai.com> References: <1437508781-28655-1-git-send-email-emunson@akamai.com> <1437508781-28655-3-git-send-email-emunson@akamai.com> Message-ID: <55AF5F5A.3000707@suse.cz> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 07/21/2015 09:59 PM, Eric B Munson wrote: > With the refactored mlock code, introduce new system calls for mlock, > munlock, and munlockall. The new calls will allow the user to specify > what lock states are being added or cleared. mlock2 and munlock2 are > trivial at the moment, but a follow on patch will add a new mlock state > making them useful. > > munlock2 addresses a limitation of the current implementation. If a ^ munlockall2? > user calls mlockall(MCL_CURRENT | MCL_FUTURE) and then later decides > that MCL_FUTURE should be removed, they would have to call munlockall() > followed by mlockall(MCL_CURRENT) which could potentially be very > expensive. The new munlockall2 system call allows a user to simply > clear the MCL_FUTURE flag. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by kanga.kvack.org (Postfix) with ESMTP id 4DB8D9003C7 for ; Wed, 22 Jul 2015 05:16:20 -0400 (EDT) Received: by wibxm9 with SMTP id xm9so92205420wib.1 for ; Wed, 22 Jul 2015 02:16:19 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id bt2si1403076wjb.200.2015.07.22.02.16.17 for (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jul 2015 02:16:18 -0700 (PDT) Message-ID: <55AF5F5A.3000707@suse.cz> Date: Wed, 22 Jul 2015 11:16:10 +0200 From: Vlastimil Babka MIME-Version: 1.0 Subject: Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls References: <1437508781-28655-1-git-send-email-emunson@akamai.com> <1437508781-28655-3-git-send-email-emunson@akamai.com> In-Reply-To: <1437508781-28655-3-git-send-email-emunson@akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Eric B Munson , Andrew Morton Cc: Michal Hocko , Heiko Carstens , Geert Uytterhoeven , Catalin Marinas , Stephen Rothwell , Guenter Roeck , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, linux-cris-kernel@axis.com, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@linux-mips.org, linux-am33-list@redhat.com, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org On 07/21/2015 09:59 PM, Eric B Munson wrote: > With the refactored mlock code, introduce new system calls for mlock, > munlock, and munlockall. The new calls will allow the user to specify > what lock states are being added or cleared. mlock2 and munlock2 are > trivial at the moment, but a follow on patch will add a new mlock state > making them useful. > > munlock2 addresses a limitation of the current implementation. If a ^ munlockall2? > user calls mlockall(MCL_CURRENT | MCL_FUTURE) and then later decides > that MCL_FUTURE should be removed, they would have to call munlockall() > followed by mlockall(MCL_CURRENT) which could potentially be very > expensive. The new munlockall2 system call allows a user to simply > clear the MCL_FUTURE flag. > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756452AbbGVJQX (ORCPT ); Wed, 22 Jul 2015 05:16:23 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58851 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932539AbbGVJQU (ORCPT ); Wed, 22 Jul 2015 05:16:20 -0400 Message-ID: <55AF5F5A.3000707@suse.cz> Date: Wed, 22 Jul 2015 11:16:10 +0200 From: Vlastimil Babka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric B Munson , Andrew Morton CC: Michal Hocko , Heiko Carstens , Geert Uytterhoeven , Catalin Marinas , Stephen Rothwell , Guenter Roeck , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, adi-buildroot-devel@lists.sourceforge.net, linux-cris-kernel@axis.com, linux-ia64@vger.kernel.org, linux-m68k@vger.kernel.org, linux-mips@linux-mips.org, linux-am33-list@redhat.com, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH V4 2/6] mm: mlock: Add new mlock, munlock, and munlockall system calls References: <1437508781-28655-1-git-send-email-emunson@akamai.com> <1437508781-28655-3-git-send-email-emunson@akamai.com> In-Reply-To: <1437508781-28655-3-git-send-email-emunson@akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/21/2015 09:59 PM, Eric B Munson wrote: > With the refactored mlock code, introduce new system calls for mlock, > munlock, and munlockall. The new calls will allow the user to specify > what lock states are being added or cleared. mlock2 and munlock2 are > trivial at the moment, but a follow on patch will add a new mlock state > making them useful. > > munlock2 addresses a limitation of the current implementation. If a ^ munlockall2? > user calls mlockall(MCL_CURRENT | MCL_FUTURE) and then later decides > that MCL_FUTURE should be removed, they would have to call munlockall() > followed by mlockall(MCL_CURRENT) which could potentially be very > expensive. The new munlockall2 system call allows a user to simply > clear the MCL_FUTURE flag. >