On (05/13/16 16:20), Minchan Kim wrote: [..] > > here I assume that the biggest contributor to re-compress latency is > > enabled preemption after zcomp_strm_release() and this second zs_malloc(). > > the compression itself of a PAGE_SIZE buffer should be fast enough. so IOW > > we would pass down the slow path, but would not account it. > > biggest contributors are 1. direct reclaim by second zsmalloc call + > 2. recompression overhead. 3. enabled preemption after zcomp_strm_release() we can be scheduled out for a long time. > If zram start to support high comp ratio but slow speed algorithm like zlib > 2 might be higher than 1 in the future so let's not ignore 2 overhead. hm, yes, good point. not arguing, just for notice -- 2) has an upper limit on its complexity, because we basically just do a number of arithmetical operations on a buffer that has upper size limit -- PAGE_SIZE; while reclaim in zsmalloc() can last an arbitrary amount of time. that's why I tend to think of a PAGE_SIZE compression contribution as of constant, that can be ignored. > Although 2 is smaller, your patch just accounts only direct reclaim but my > suggestion can count both 1 and 2 so isn't it better? > > I don't know why it's arguable here. :) no objections to put it next to goto. just making sure that we have considered all the possibilities and cases. will resend shortly, thanks! -ss -- 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>