[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E738CF6.4020808@vflare.org>
Date:	Fri, 16 Sep 2011 13:52:54 -0400
From:	Nitin Gupta <ngupta@...are.org>
To:	Seth Jennings <sjenning@...ux.vnet.ibm.com>
CC:	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Greg KH <greg@...ah.com>, gregkh@...e.de,
	devel@...verdev.osuosl.org, cascardo@...oscopio.com,
	linux-kernel@...r.kernel.org, dave@...ux.vnet.ibm.com,
	linux-mm@...ck.org, brking@...ux.vnet.ibm.com,
	rcj@...ux.vnet.ibm.com
Subject: Re: [PATCH v2 0/3] staging: zcache: xcfmalloc support
On 09/15/2011 03:24 PM, Seth Jennings wrote:
> On 09/15/2011 12:29 PM, Dan Magenheimer wrote:
>>> From: Seth Jennings [mailto:sjenning@...ux.vnet.ibm.com]
>>> Subject: Re: [PATCH v2 0/3] staging: zcache: xcfmalloc support
>>>
>>
>> Seth, I am still not clear why it is not possible to support
>> either allocation algorithm, selectable at runtime.  Or even
>> dynamically... use xvmalloc to store well-compressible pages
>> and xcfmalloc for poorly-compressible pages.  I understand
>> it might require some additional coding, perhaps even an
>> ugly hack or two, but it seems possible.
> 
> But why do an ugly hack if we can just use a single allocator
> that has the best overall performance for the allocation range
> the zcache requires.  Why make it more complicated that it
> needs to be?
> 
>>
I agree with Seth here: a mix of different allocators for the (small)
range of sizes which zcache requires, looks like a bad idea to me.
Maintaining two allocators is a pain and this will also complicate
future plans like compaction etc.
Thanks,
Nitin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Powered by blists - more mailing lists
 
