From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 9C5E399A for ; Fri, 13 Jun 2014 23:04:55 +0000 (UTC) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id D028B201B3 for ; Fri, 13 Jun 2014 23:04:54 +0000 (UTC) Date: Fri, 13 Jun 2014 18:04:52 -0500 (CDT) From: Christoph Lameter To: Benjamin Herrenschmidt In-Reply-To: <1402695366.20360.14.camel@pasglop> Message-ID: References: <53994FED.1080106@lougher.demon.co.uk> <1402695366.20360.14.camel@pasglop> Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [CORE TOPIC] Redesign Memory Management layer and more core subsystem List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, 14 Jun 2014, Benjamin Herrenschmidt wrote: > > It is solvable if the objects are inherent movable. If any object > > allocated provides a function that makes an object movable then > > defragmentation is possible and therefore large contiguous area of memory > > can be created at any time. > > Another interesting thing is migration of pages with mapped DMA on > them :-) > > Our IOMMUs support that, but there isn't a way to hook that up into > Linux page migration that wouldn't suck massively at this point. Well yes that would require a major rethink. While we are at it we may as well try to get more done. Maybe we can do that just for a limited region within the existing memory management. Something like OSV, cgroups or cpuset that restricts it to certain nodes or cpus where we would allow this to occur while the rest still runs the standard kernel. A kind of sidecar approach.