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

Nitin Gupta
2009-04-02T00:04:13Z

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