From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752141AbaE0Kyv (ORCPT ); Tue, 27 May 2014 06:54:51 -0400 Received: from casper.infradead.org ([85.118.1.10]:37076 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751734AbaE0Kyt (ORCPT ); Tue, 27 May 2014 06:54:49 -0400 Date: Tue, 27 May 2014 12:54:38 +0200 From: Peter Zijlstra To: Konstantin Khlebnikov Cc: "linux-mm@kvack.org" , Linux Kernel Mailing List , Christoph Lameter , Thomas Gleixner , Andrew Morton , Hugh Dickins , Mel Gorman , Roland Dreier , Sean Hefty , Hal Rosenstock , Mike Marciniszyn Subject: Re: [RFC][PATCH 0/5] VM_PINNED Message-ID: <20140527105438.GW13658@twins.programming.kicks-ass.net> References: <20140526145605.016140154@infradead.org> <20140526203232.GC5444@laptop.programming.kicks-ass.net> <20140527102909.GO30445@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JHjDRUnf1JOMxzko" Content-Disposition: inline In-Reply-To: <20140527102909.GO30445@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --JHjDRUnf1JOMxzko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 27, 2014 at 12:29:09PM +0200, Peter Zijlstra wrote: > On Tue, May 27, 2014 at 12:49:08AM +0400, Konstantin Khlebnikov wrote: > > Another suggestion. VM_RESERVED is stronger than VM_LOCKED and extends > > its functionality. > > Maybe it's easier to add VM_DONTMIGRATE and use it together with VM_LOC= KED. > > This will make accounting easier. No? >=20 > I prefer the PINNED name because the not being able to migrate is only > one of the desired effects of it, not the primary effect. We're really > looking to keep physical pages in place and preserve mappings. >=20 > The -rt people for example really want to avoid faults (even minor > faults), and DONTMIGRATE would still allow unmapping. >=20 > Maybe always setting VM_PINNED and VM_LOCKED together is easier, I > hadn't considered that. The first thing that came to mind is that that > might make the fork() semantics difficult, but maybe it works out. >=20 > And while we're on the subject, my patch preserves PINNED over fork() > but maybe we don't actually need that either. So pinned_vm is userspace exposed, which means we have to maintain the individual counts, and doing the fully orthogonal accounting is 'easier' than trying to get the boundary cases right. That is, if we have a program that does mlockall() and then does the IB ioctl() to 'pin' a region, we'd have to make mm_mpin() do munlock() after it splits the vma, and then do the pinned accounting. Also, we'll have lost the LOCKED state and unless MCL_FUTURE was used, we don't know what to restore the vma to on mm_munpin(). So while the accounting looks tricky, it has simpler semantics. --JHjDRUnf1JOMxzko Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJThG7uAAoJEHZH4aRLwOS6eAIQALZlA3uluTkf8/ciEiNoNzcm O+a5nh6AC26jmjZ2Y732YdRo4hC00pK2TTj2uQ32sNteklK4VMB8ZrYwOArfV6mF zrj2zU1RlLkU1CkyIdF3UOhzzOf9F3TuEGVk3AuWVv33ybrdwQXLKKHzveczespg WWSEvRsSGcqQUGefmS9czAJVArk/AV0Rg+3BYucPYn036yJ2+a6Kw+rTtObASSxN +UV7lTzBIg7HgxRweS6jZ18Q/FKG4fGE+RHXPBpT2sFdrVMq4A+QeFTGZ9WPDcvP spaNc+fr012RcVHWwLylGTkj/r9NwAv43K1TnsI5zTWMUrzDh8SGgsHsAWu6C8IK lpax0WSdfWn2MnAXhuEzGLoLuyTUwSXsudASaqaDdSmBMu1Ur/NZmlw3qGci5SUw 0ORPj4/vPRFHaNI9Gg22fwtOTHqTOey710J2FpRtdEYxFpeAGFIfHTucj4Zal9Gu SraZSECzMaadd1Sz6EXjiMGgau26q62aikcOYpDFvtKxe6RGEdIS6oYuQeDNPADp +bz08PDsdm+IJDKKctOnmKQoICljHFqKmZCLSz/HY/ybTf+G6BB0qgPnTRofIFtC 6Ry7OZHTzaaJ0kfVhTxx45US63Vtoj69lQdTUnXnJDTuu3mu2VW6Dxyt51YikldN OQ+5smSQteJyV4P7hOZ/ =I0k+ -----END PGP SIGNATURE----- --JHjDRUnf1JOMxzko--