lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4EB0AE0E.8040709@vflare.org>
Date:	Tue, 01 Nov 2011 22:42:22 -0400
From:	Nitin Gupta <ngupta@...are.org>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
CC:	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	Greg KH <greg@...ah.com>, gregkh@...e.de,
	devel@...verdev.osuosl.org, cascardo@...oscopio.com,
	linux-kernel@...r.kernel.org, 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 11/01/2011 02:35 PM, Dan Magenheimer wrote:

>> From: Dave Hansen [mailto:dave@...ux.vnet.ibm.com]
>> Sent: Tuesday, November 01, 2011 11:30 AM
>> To: Nitin Gupta
>> Cc: Seth Jennings; Greg KH; gregkh@...e.de; devel@...verdev.osuosl.org; Dan Magenheimer;
>> cascardo@...oscopio.com; linux-kernel@...r.kernel.org; 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 Fri, 2011-09-16 at 13:46 -0400, Nitin Gupta wrote:
>>> I think replacing allocator every few weeks isn't a good idea. So, I
>>> guess better would be to let me work for about 2 weeks and try the slab
>>> based approach.  If nothing works out in this time, then maybe xcfmalloc
>>> can be integrated after further testing.
>>
>> Hi Nitin,
>>
>> It's been about six weeks. :)
>>
>> Can we talk about putting xcfmalloc() in staging now?
> 
> FWIW, given that I am quoting "code rules!" to the gods of Linux
> on another lkml thread, I can hardly disagree here.
> 


I agree with you Dan. It took me really long to bring the new allocator
into some shape and still I'm not very confident that it's ready to be
integrated with zcache.

> If Nitin continues to develop his allocator and it proves
> better than xcfmalloc (and especially if it can replace
> zbud as well), we can consider replacing xcfmalloc later.
> Until zcache is promoted from staging, I think we have
> that flexibility.
> 


Agreed.  Though I still consider slab based design much better, having
already tried xcfmalloc like design much earlier in the project history,
I would still favor xcfmalloc integration since xvmalloc weakness with
>PAGE_SIZE/2 objects is probably too much to bear.


> (Shameless advertisement though:  The xcfmalloc allocator
> only applies to pages passed via frontswap, and on
> that other lkml thread lurk many people intent on shooting
> frontswap down.  So, frankly, I'd prefer time to be spent
> on benchmarking zcache rather than on arguing about
> allocators which, as things currently feel to me on that
> other lkml thread, is not unlike rearranging deck chairs
> on the Titanic. Half-:-).
> 
>


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ