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
| ||
|
Date: Thu, 02 Apr 2009 05:32:45 +0530 From: Nitin Gupta <nitingupta910@...il.com> To: Andrew Morton <akpm@...ux-foundation.org> CC: penberg@...helsinki.fi, cl@...ux-foundation.org, edt@....ca, linux-mm-cc@...top.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/3] compressed in-memory swapping take5 Hi Andrew, Thanks for your reply. My comments inline. Andrew Morton wrote: >> - Links to more performance numbers, use cases can be found at: >> http://lkml.org/lkml/2009/3/17/116 > > The sole, whole, entire point of this patchset is performance. Yet > after chasing a few scruffy links, the only data we have to justify > merging _any_ of this stuff is, and I quote, > > - The time of paging down one pdf page was reduced to 1/4~1/100 > - The time of switching from one firefox tab to another was reduced to 1/6 > - The capacity of kpdf was be increased from 2 pdf files to 11 pdf files. > - The capacity of firefox was increased from 6 web pages to 15 web pages. > > that isn't very compelling! > > So would it be possible for you to come up with some more concrete > testing results to help convince us that we should make this change to > Linux? And include them front-and-centre in the changelog, and > maintain it? > Fair enough. I will get these numbers and include them in changelog itself. Probably by next kernel release. > We would also be interested in seeing the performance _loss_ from these > patches. There must be some cost somewhere. Find a worstish-case test > case and run it and include its results in the changelog too, so we > better understand the tradeoffs involved here. > Sure. I will get these too. > > I'm really reluctant to go and merge a complete new memory allocator > just on behalf of an obscure driver. Oh well, perhaps hiding it down > in drivers/block was the right thing to do. Justification for this custom allocator is present in xvmalloc changelog itself. It gives reason for not using SLUB and SLOB. During review cycle, I never got any arguments against that justification. For possible inclusion in Linux, I will hide it in drivers/block/ramzswap and rename interfaces to make sure that no-one else can use it. > > As the patchset adds five tightly-related files, perhaps it should all > live in drivers/block/rmazswap/? > > Ok, no problem. Thanks for reply. 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