Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261248AbVDZCDl (ORCPT ); Mon, 25 Apr 2005 22:03:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261255AbVDZCDl (ORCPT ); Mon, 25 Apr 2005 22:03:41 -0400 Received: from sv1.valinux.co.jp ([210.128.90.2]:12980 "EHLO sv1.valinux.co.jp") by vger.kernel.org with ESMTP id S261248AbVDZCDj (ORCPT ); Mon, 25 Apr 2005 22:03:39 -0400 Date: Tue, 26 Apr 2005 11:03:38 +0900 From: IWAMOTO Toshihiro To: Roland Dreier Cc: Andrew Morton , Timur Tabi , hch@infradead.org, hozer@hozed.org, linux-kernel@vger.kernel.org, openib-general@openib.org Subject: Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation In-Reply-To: <52vf6atnn8.fsf@topspin.com> References: <200544159.Ahk9l0puXy39U6u6@topspin.com> <20050411142213.GC26127@kalmia.hozed.org> <52mzs51g5g.fsf@topspin.com> <20050411163342.GE26127@kalmia.hozed.org> <5264yt1cbu.fsf@topspin.com> <20050411180107.GF26127@kalmia.hozed.org> <52oeclyyw3.fsf@topspin.com> <20050411171347.7e05859f.akpm@osdl.org> <4263DEC5.5080909@ammasso.com> <20050418164316.GA27697@infradead.org> <4263E445.8000605@ammasso.com> <20050423194421.4f0d6612.akpm@osdl.org> <426BABF4.3050205@ammasso.com> <52is2bvvz5.fsf@topspin.com> <20050425135401.65376ce0.akpm@osdl.org> <521x8yv9vb.fsf@topspin.com> <20050425151459.1f5fb378.akpm@osdl.org> <426D6D68.6040504@ammasso.com> <20050425153256.3850ee0a.akpm@osdl.org> <52vf6atnn8.fsf@topspin.com> User-Agent: Wanderlust/2.11.30 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050426020338.5909570488@sv1.valinux.co.jp> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1148 Lines: 26 At Mon, 25 Apr 2005 16:58:03 -0700, Roland Dreier wrote: > Andrew> It would be better to obtain this memory via a mmap() of > Andrew> some special device node, so we can perform appropriate > Andrew> permission checking and clean everything up on unclean > Andrew> application exit. > > This seems to interact poorly with how applications want to use RDMA, > ie typically through a library interface such as MPI. People doing > HPC don't want to recode their apps to use a new allocator, they just > want to link to a new MPI library and have the app go fast. Such HPC users cannot use the memory hotremoval feature, and something needs to be implemented so that the NUMA migration can handle such memory properly, but I see your point. If such memory were allocated by a driver, the memory could be placed in non-hotremovable areas to avoid the above problems. -- IWAMOTO Toshihiro - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/