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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>