From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <43D09FA5.50806@jp.fujitsu.com> Date: Fri, 20 Jan 2006 17:30:29 +0900 From: KAMEZAWA Hiroyuki MIME-Version: 1.0 Subject: Re: [PATCH 1/2] Add the pzone References: <20060119080408.24736.13148.sendpatchset@debian> <20060119080413.24736.27946.sendpatchset@debian> <43D08C6C.1000802@jp.fujitsu.com> <20060120082242.8BEE57402D@sv1.valinux.co.jp> In-Reply-To: <20060120082242.8BEE57402D@sv1.valinux.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: KUROSAWA Takahiro Cc: ckrm-tech@lists.sourceforge.net, linux-mm@kvack.org List-ID: KUROSAWA Takahiro wrote: >> It looks you don't want to use functions based on zones, buddy-system, lru-list etc.. >> I think what you want is just a hierarchical memory allocator. >> Why do you modify zone and make codes complicated ? >> Can your memory allocater be implimented like mempool or hugetlb ? >> They are not so invasive. > > mempool and hugetlb require their own shrinking code, don't they? > I guess that we would need the routines like mm/vmscan.c if we are > going to shrink user pages. Instead, I'd like to reuse the shrinking > code in mm/vmscan.c. > I think you can reuse shrink_list() at least. Code duplication you're afraid of can be small. I think call shrink_list() from your own shrinking fuction will add good control on CKRM's memory region. -- Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org