Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752953Ab0HZCll (ORCPT ); Wed, 25 Aug 2010 22:41:41 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:42024 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751742Ab0HZClh convert rfc822-to-8bit (ORCPT ); Wed, 25 Aug 2010 22:41:37 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Thu, 26 Aug 2010 04:40:46 +0200 From: =?utf-8?B?TWljaGHFgiBOYXphcmV3aWN6?= Subject: Re: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework In-reply-to: <20100825155814.25c783c7.akpm@linux-foundation.org> To: Peter Zijlstra , Andrew Morton Cc: Hans Verkuil , Daniel Walker , Russell King , Jonathan Corbet , Mel Gorman , Pawel Osciak , Konrad Rzeszutek Wilk , linux-kernel@vger.kernel.org, FUJITA Tomonori , linux-mm@kvack.org, Kyungmin Park , Zach Pfeffer , Mark Brown , linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Marek Szyprowski Message-id: Organization: Samsung Electronics Content-transfer-encoding: 8BIT User-Agent: Opera Mail/10.61 (Linux) References: <1282310110.2605.976.camel@laptop> <20100825155814.25c783c7.akpm@linux-foundation.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3004 Lines: 66 Hello Andrew, I think Pawel has replied to most of your comments, so I'll just add my own 0.02 KRW. ;) > Peter Zijlstra wrote: >> So the idea is to grab a large chunk of memory at boot time and then >> later allow some device to use it? >> >> I'd much rather we'd improve the regular page allocator to be smarter >> about this. We recently added a lot of smarts to it like memory >> compaction, which allows large gobs of contiguous memory to be freed for >> things like huge pages. >> >> If you want guarantees you can free stuff, why not add constraints to >> the page allocation type and only allow MIGRATE_MOVABLE pages inside a >> certain region, those pages are easily freed/moved aside to satisfy >> large contiguous allocations. On Thu, 26 Aug 2010 00:58:14 +0200, Andrew Morton wrote: > That would be good. Although I expect that the allocation would need > to be 100% rock-solid reliable, otherwise the end user has a > non-functioning device. Could generic core VM provide the required level > of service? I think that the biggest problem is fragmentation here. For instance, I think that a situation where there is enough free space but it's fragmented so no single contiguous chunk can be allocated is a serious problem. However, I would argue that if there's simply no space left, a multimedia device could fail and even though it's not desirable, it would not be such a big issue in my eyes. So, if only movable or discardable pages are allocated in CMA managed regions all should work well. When a device needs memory discardable pages would get freed and movable moved unless there is no space left on the device in which case allocation would fail. Critical devices (just a hypothetical entities) could have separate regions on which only discardable pages can be allocated so that memory can always be allocated for them. > I agree that having two "contiguous memory allocators" floating about > on the list is distressing. Are we really all 100% diligently certain > that there is no commonality here with Zach's work? As Pawel said, I think Zach's trying to solve a different problem. No matter, as I've said in response to Konrad's message, I have thought about unifying Zach's IOMMU and CMA in such a way that devices could work on both systems with and without IOMMU if only they would limit the usage of the API to some subset which always works. > Please cc me on future emails on this topic? Not a problem. -- Best regards, _ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo-- -- 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/