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