| 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
| ||
|
Message-ID: <4E725109.3010609@linux.vnet.ibm.com> Date: Thu, 15 Sep 2011 14:24:57 -0500 From: Seth Jennings <sjenning@...ux.vnet.ibm.com> To: Dan Magenheimer <dan.magenheimer@...cle.com> CC: Nitin Gupta <ngupta@...are.org>, 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 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 >> >> Hey Nitin, >> >> So this is how I see things... >> >> Right now xvmalloc is broken for zcache's application because >> of its huge fragmentation for half the valid allocation sizes >> (> PAGE_SIZE/2). > > Um, I have to disagree here. It is broken for zcache for > SOME set of workloads/data, where the AVERAGE compression > is poor (> PAGE_SIZE/2). > True. But are we not in agreement that xvmalloc needs to be replaced with an allocator that doesn't have this issue? I thought we all agreed on that... >> My xcfmalloc patches are _a_ solution that is ready now. Sure, >> it doesn't so compaction yet, and it has some metadata overhead. >> So it's not "ideal" (if there is such I thing). But it does fix >> the brokenness of xvmalloc for zcache's application. > > But at what cost? As Dave Hansen pointed out, we still do > not have a comprehensive worst-case performance analysis for > xcfmalloc. Without that (and without an analysis over a very > large set of workloads), it is difficult to characterize > one as "better" than the other. > I'm not sure what you mean by "comprehensive worst-case performance analysis". If you're talking about theoretical worst-case runtimes (i.e. O(whatever)) then apparently we are going to have to talk to an authority on algorithm analysis because we can't agree how to determine that. However, it isn't difficult to look at the code and (within your own understanding) see what it is. I'd be interested so see what Nitin thinks is the worst-case runtime bound. How would you suggest that I measure xcfmalloc performance on a "very large set of workloads". I guess another form of that question is: How did xvmalloc do this? >> So I see two ways going forward: >> >> 1) We review and integrate xcfmalloc now. Then, when you are >> done with your allocator, we can run them side by side and see >> which is better by numbers. If yours is better, you'll get no >> argument from me and we can replace xcfmalloc with yours. >> >> 2) We can agree on a date (sooner rather than later) by which your >> allocator will be completed. At that time we can compare them and >> integrate the best one by the numbers. >> >> Which would you like to do? > > 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? > > Dan -- 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