Re: [PATCH 0/2] prepare zbud to be used by zram as underlying allocator

[Vitaly Wool]

Hello Minchan,

> Sorry, because you wrote up "zram" in the title.
> As I said earlier, we need several numbers to investigate.
>
> First of all, what is culprit of your latency?
> It seems you are thinking about compaction. so compaction what?
> Frequent scanning? lock collision? or frequent sleeping in compaction
> code somewhere? And then why does zbud solve it? If we use zbud for zram,
> we lose memory efficiency so there is something to justify it.

The data I've got so far strongly suggests that in some use cases (see
below) with zsmalloc
* there are more allocstalls
* memory compaction is triggered more frequently
* allocstalls happen more often
* page migrations are way more frequent, too.

Please also keep in mind that I do not advise you or anyone to use
zbud instead of zsmalloc. The point I'm trying to make is that zbud
fits my particular case better and I want to be able to choose it in
the kernel without hacking it with my private patches.
FWIW, given that I am not an author of either, I don't see why anyone
would consider me biased. :-)

As of the memory efficiency, you seem to be quite comfortable with
storing uncompressed pages when they compress to more than 3/4 of a
page. I observed ~13% reported ratio increase (3.8x to 4.3x) when I
increased max_zpage_size to PAGE_SIZE / 32 * 31. Doesn't look like a
fight for every byte to me.

> The reason I am asking is I have investigated similar problems
> in android and other plaforms and the reason of latency was not zsmalloc
> but agressive high-order allocations from subsystems, watermark check
> race, deferring of compaction, LMK not working and too much swapout so
> it causes to reclaim lots of page cache pages which was main culprit
> in my cases. When I checks with perf, compaction stall count is increased,
> the time spent in there is not huge so it was not main factor of latency.

The main use case where the difference is seen is switching between
users on an Android device. It does cause a lot of reclaim, too, as
you say, but this is in the nature of zbud that reclaim happens in a
more deterministic way and worst-case looks substantially nicer. That
said, the standard deviation calculated over 20 iterations of a
change-user-multiple-times-test is 2x less for zbud than the one of
zsmalloc.

I'll post some numbers in the next patch respin so they won't get lost :)

~vitaly
--
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/