[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5106B83E.2030804@linux.vnet.ibm.com>
Date: Mon, 28 Jan 2013 11:41:18 -0600
From: Seth Jennings <sjenning@...ux.vnet.ibm.com>
To: Minchan Kim <minchan@...nel.org>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Nitin Gupta <ngupta@...are.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Dan Magenheimer <dan.magenheimer@...cle.com>,
Robert Jennings <rcj@...ux.vnet.ibm.com>,
Jenifer Hopper <jhopper@...ibm.com>,
Mel Gorman <mgorman@...e.de>,
Johannes Weiner <jweiner@...hat.com>,
Rik van Riel <riel@...hat.com>,
Larry Woodman <lwoodman@...hat.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org
Subject: Re: [PATCHv2 6/9] zsmalloc: promote to lib/
On 01/27/2013 10:32 PM, Minchan Kim wrote:
> On Mon, Jan 28, 2013 at 01:01:16PM +0900, Minchan Kim wrote:
>> On Mon, Jan 07, 2013 at 02:24:37PM -0600, Seth Jennings wrote:
>>> This patch promotes the slab-based zsmalloc memory allocator
>>> from the staging tree to lib/
>>>
>>> zswap depends on this allocator for storing compressed RAM pages
>>> in an efficient way under system wide memory pressure where
>>> high-order (greater than 0) page allocation are very likely to
>>> fail.
>>>
>>> For more information on zsmalloc and its internals, read the
>>> documentation at the top of the zsmalloc.c file.
>>>
>>> Signed-off-by: Seth Jennings <sjenning@...ux.vnet.ibm.com>
>>
>> Seth, zsmalloc has a bug[1], I sent a patch totay. If it want't known,
>> it mighte be no problem to promote but it's known bug so let's fix it
>> before promoting.
>>
>> Another question. Why do you promote zsmalloc in this patchset?
>> It might make you hard to merge even zswap into staging.
>
> When I look at [8/9], I realized you are trying to merge this patch
> into mm/, NOT staging. I don't know history why zsmalloc/zram/zscache was
> in staging at the beginning but personally, I don't ojbect zswap into /mm
> directly because I got realized staging is very deep hole to get out,
> expecially related to mm stuff. ;-)
Correct.
As I understand the purpose of the staging tree, it is meant for
drivers whose code doesn't adhere to the kernel coding
standards/guidelines and might have questionable stability. The point
is to have a TODO, get the code to conform to the kernel standards,
fix known instabilities, then promote into the appropriate place in
the driver tree.
However, with the work on memory compression, it's really become a
prototyping area, which I don't think Greg likes all that much.
Seth
--
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