From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261248AbUDHKTK (ORCPT ); Thu, 8 Apr 2004 06:19:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261460AbUDHKTJ (ORCPT ); Thu, 8 Apr 2004 06:19:09 -0400 Received: from sv1.valinux.co.jp ([210.128.90.2]:40404 "EHLO sv1.valinux.co.jp") by vger.kernel.org with ESMTP id S261248AbUDHKTG (ORCPT ); Thu, 8 Apr 2004 06:19:06 -0400 Date: Thu, 08 Apr 2004 19:19:04 +0900 From: IWAMOTO Toshihiro To: "Martin J. Bligh" Cc: IWAMOTO Toshihiro , linux-kernel@vger.kernel.org, lhms-devel@lists.sourceforge.net Subject: Re: [Lhms-devel] Re: [patch 0/3] memory hotplug prototype In-Reply-To: <20040408091610.65C29706C3@sv1.valinux.co.jp> References: <20040406105353.9BDE8705DE@sv1.valinux.co.jp> <29700000.1081361575@flay> <20040408091610.65C29706C3@sv1.valinux.co.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-Id: <20040408101904.D6ED4706C3@sv1.valinux.co.jp> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org At Thu, 08 Apr 2004 18:16:10 +0900, IWAMOTO Toshihiro wrote: > > At Wed, 07 Apr 2004 11:12:55 -0700, > Martin J. Bligh wrote: > > > > > This is an updated version of memory hotplug prototype patch, which I > > > have posted here several times. > > > > I really, really suggest you take a look at Dave McCracken's work, which > > he posted as "Basic nonlinear for x86" recently. It's going to be much > > much easier to use this abstraction than creating 1000s of zones ... > > Well, I think his patch is orthogonal to mine. My ultimate target > is IA64 and it will only support node-sized memory hotplugging. > > If you need fine-grained memory resizing, that shouldn't be hard to > do. As others have pointed out, per section hotremovable is not as > easy as per zone one, but we've done a similar thing for hugetlbfs > support. Look for PG_again in Takahashi's patch. Err, s/PG_again/PG_booked/ Pages with PG_booked bit set are skipped in alloc_pages. Alternatively, when such pages are freed, they can be linked to another list than free_list to avoid being used again, but buddy bits handling would be a bit tricky in this case. -- IWAMOTO Toshihiro