Re: [PATCH 0/3] compressed in-memory swapping take5

From: Nitin Gupta
Date: Wed Apr 01 2009 - 20:04:13 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/