Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750922AbVKAQ76 (ORCPT ); Tue, 1 Nov 2005 11:59:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750923AbVKAQ76 (ORCPT ); Tue, 1 Nov 2005 11:59:58 -0500 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:434 "EHLO fgwmail5.fujitsu.co.jp") by vger.kernel.org with ESMTP id S1750911AbVKAQ75 (ORCPT ); Tue, 1 Nov 2005 11:59:57 -0500 Message-ID: <43679EE6.7000706@jp.fujitsu.com> Date: Wed, 02 Nov 2005 01:59:18 +0900 From: Kamezawa Hiroyuki User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kamezawa Hiroyuki CC: Ingo Molnar , Dave Hansen , Mel Gorman , Nick Piggin , "Martin J. Bligh" , Andrew Morton , kravetz@us.ibm.com, linux-mm , Linux Kernel Mailing List , lhms Subject: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 References: <4366A8D1.7020507@yahoo.com.au> <4366C559.5090504@yahoo.com.au> <4366D469.2010202@yahoo.com.au> <20051101135651.GA8502@elte.hu> <1130854224.14475.60.camel@localhost> <20051101142959.GA9272@elte.hu> <1130856555.14475.77.camel@localhost> <20051101150142.GA10636@elte.hu> <43679C69.6050107@jp.fujitsu.com> In-Reply-To: <43679C69.6050107@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1588 Lines: 37 Kamezawa Hiroyuki wrote: > Ingo Molnar wrote: > >> so it's all about expectations: _could_ you reasonably remove a piece >> of RAM? Customer will say: "I have stopped all nonessential services, >> and free RAM is at 90%, still I cannot remove that piece of faulty >> RAM, fix the kernel!". No reasonable customer will say: "True, I have >> all RAM used up in mlock()ed sections, but i want to remove some RAM >> nevertheless". >> > Hi, I'm one of men in -lhms > > In my understanding... > - Memory Hotremove on IBM's LPAR? approach is > [remove some amount of memory from somewhere.] > For this approach, Mel's patch will work well. > But this will not guaranntee a user can remove specified range of > memory at any time because how memory range is used is not defined by > an admin > but by the kernel automatically. But to extract some amount of memory, > Mel's patch is very important and they need this. > One more consideration... Some cpus which support virtialization will be shipped by some vendor in near future. If someone uses vitualized OS, only problem is *resizing*. Hypervisor will be able to remap semi-physical pages anyware with hardware assistance but system resizing needs operating system assistance. To this direction, [remove some amount of memory from somewhere.] is important approach. -- Kame - 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/