[<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