> > Do you have any data comparing xcfmalloc vs xvmalloc for > > compression ratio and/or performance (cycles to compress > > or decompress different pages) on a wide(r) range of data? > > Assuming xcfmalloc isn't "always better", maybe it would > > be best to allow the algorithm to be selectable? (And > > then we would also need to decide the default.) > > > > I can get you some results comparing the two tomorrow. > > You have to make the distinction between the > "compression ratio" and the "effective compression". > The compression ratio is the same since the compression > algorithm, LZO, was changed. The effective compression, changed -> NOT changed, correct? LZO is used in both? I had forgotten that, so the only issue might be the overhead. > the ratio of stored compressed pages to allocator pool > pages, is different between the two, especially for > allocation sets > PAGE_SIZE/2. > What the numbers will tell you is that for allocations sets > < PAGE_SIZE/2 xcfmalloc is a little worse (~2% greater > overhead). But for allocation sets > PAGE_SIZE/2, > xcfmalloc has up to a 50% advantage over xvmalloc. > > As far as performance numbers, all I can see is that > the throughput is the same between the two. I'm not > sure how to get, for example, and cycles delta > between the two. IIRC, xvmalloc has O(1) overhead regardless of the number of chunks of data stored. Some algorithms are O(N) or even O(N**2), i.e. might walk a potentially increasingly very long list of allocations/descriptors to find a slot, which would not be acceptable for zcache as, for a large data set, the overhead might be much worse than the cycles-to-compress. Which is xcfmalloc, O(1) or O(N) or O(N**2)? (Also, since I think interrupts are still disabled, reading the tsc before/after should be safe to get the cycles delta.) > I would be difficult to make it selectable because the > function signatures (and some concepts) aren't the same. > You can see the changes that were required in the patch > 2/3. Then I definitely would like to see some review and discussion from Nitin. Clearly xcfmalloc is better for poorly-compressible data; I would like to be confident that it is not "worse" for another large common set of data. An even better implementation could be if both are active and the selection is made at runtime depending on the compressibility of the data, i.e. poorly-compressible data gets stored in xcfmalloc and other data in xvmalloc? Probably not worth the effort, but food for thought. Thanks, Dan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
