From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by kanga.kvack.org (Postfix) with ESMTP id B860F6B012E for ; Tue, 11 Nov 2014 15:44:07 -0500 (EST) Received: by mail-pa0-f53.google.com with SMTP id kx10so11330193pab.40 for ; Tue, 11 Nov 2014 12:44:07 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com. [134.134.136.24]) by mx.google.com with ESMTP id sz2si21049190pac.44.2014.11.11.12.44.05 for ; Tue, 11 Nov 2014 12:44:06 -0800 (PST) Message-ID: <54627512.7060806@intel.com> Date: Tue, 11 Nov 2014 12:44:02 -0800 From: Dave Hansen MIME-Version: 1.0 Subject: Re: [PATCH v9 11/12] x86, mpx: cleanup unused bound tables References: <1413088915-13428-1-git-send-email-qiaowei.ren@intel.com> <1413088915-13428-12-git-send-email-qiaowei.ren@intel.com> <545BED0B.8000001@intel.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Thomas Gleixner Cc: Qiaowei Ren , "H. Peter Anvin" , Ingo Molnar , x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, linux-mips@linux-mips.org On 11/11/2014 10:27 AM, Thomas Gleixner wrote: > On Thu, 6 Nov 2014, Dave Hansen wrote: >> Instead of all of these games with dropping and reacquiring mmap_sem and >> adding other locks, or deferring the work, why don't we just do a >> get_user_pages()? Something along the lines of: >> >> while (1) { >> ret = cmpxchg(addr) >> if (!ret) >> break; >> if (ret == -EFAULT) >> get_user_pages(addr); >> } >> >> Does anybody see a problem with that? > > You want to do that under mmap_sem write held, right? Not a problem per > se, except that you block normal faults for a possibly long time when > the page(s) need to be swapped in. Yeah, it might hold mmap_sem for write while doing this in the unmap path. But, that's only if the bounds directory entry has been swapped out. There's only 1 pointer of bounds directory entries there for every 1MB of data, so it _should_ be relatively rare. It would mean that nobody's been accessing a 512MB swath of data controlled by the same page of the bounds directory. If it gets to be an issue, we can always add some code to fault it in before mmap_sem is acquired. FWIW, I believe we have a fairly long road ahead of us to optimize MPX in practice. I have a list of things I want to go investigate, but I have not looked in to it in detail at all. > But yes, this might solve most of the issues at hand. Did not think > about GUP at all :( Whew. Fixing it was getting nasty and complicated. :) -- 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