From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by kanga.kvack.org (Postfix) with ESMTP id 4DC196B0036 for ; Tue, 27 May 2014 16:00:19 -0400 (EDT) Received: by mail-qg0-f52.google.com with SMTP id a108so14471299qge.25 for ; Tue, 27 May 2014 13:00:19 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net. [2001:558:fe2d:43:76:96:30:32]) by mx.google.com with ESMTP id 40si18547186qgf.28.2014.05.27.13.00.18 for ; Tue, 27 May 2014 13:00:18 -0700 (PDT) Date: Tue, 27 May 2014 15:00:15 -0500 (CDT) From: Christoph Lameter Subject: Re: [RFC][PATCH 0/5] VM_PINNED In-Reply-To: <20140527172930.GE11074@laptop.programming.kicks-ass.net> Message-ID: References: <20140526203232.GC5444@laptop.programming.kicks-ass.net> <20140527102909.GO30445@twins.programming.kicks-ass.net> <20140527144655.GC19143@laptop.programming.kicks-ass.net> <20140527153143.GD19143@laptop.programming.kicks-ass.net> <20140527164341.GD11074@laptop.programming.kicks-ass.net> <20140527172930.GE11074@laptop.programming.kicks-ass.net> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: Konstantin Khlebnikov , "linux-mm@kvack.org" , Linux Kernel Mailing List , Thomas Gleixner , Andrew Morton , Hugh Dickins , Mel Gorman , Roland Dreier , Sean Hefty , Hal Rosenstock , Mike Marciniszyn On Tue, 27 May 2014, Peter Zijlstra wrote: > > What do you mean by shared pages that are not shmem pages? AnonPages that > > are referenced from multiple processes? > > Regular files.. they get allocated through __page_cache_alloc(). AFAIK > there is nothing stopping people from pinning file pages for RDMA or > other purposes. Unusual maybe, but certainly not impossible, and > therefore we must be able to handle it. Typically structures for RDMA are allocated on the heap. The main use case is pinnning the executable pages in the page cache? Pinning mmapped pagecache pages may not have the desired effect if those pages are modified and need updates on disk with corresponding faults to track the dirty state etc. This may get more complicated. > > Migration is expensive and the memory registration overhead already > > causes lots of complaints. > > Sure, but first to the simple thing, then if its a problem do something > else. I thought the main issue here were the pinning of IB/RDMA buffers. -- 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