Re: [PATCH v2] zbud: allow up to PAGE_SIZE allocations

[Vitaly Wool <vitalywool@gmail.com>]

<snip>
> I already said questions, opinion and concerns but anything is not clear
> until now. Only clear thing I could hear is just "compaction stats are
> better" which is not enough for me. Sorry.
>
> 1) https://lkml.org/lkml/2015/9/15/33
> 2) https://lkml.org/lkml/2015/9/21/2

Could you please stop perverting the facts, I did answer to that:
https://lkml.org/lkml/2015/9/21/753.

Apart from that, an opinion is not necessarily something I would
answer. Concerns about zsmalloc are not in the scope of this patch's
discussion. If you have any concerns regarding this particular patch,
please let us know.

> Vitally, Please say what's the root cause of your problem and if it
> is external fragmentation, what's the problem of my approach?
>
> 1) make non-LRU page migrate
> 2) provide zsmalloc's migratpage

The problem with your approach is that in your world I need to prove
my right to use zbud. This is a very strange speculation.

> We should provide it for CMA as well as external fragmentation.
> I think we could solve your issue with above approach and
> it fundamentally makes zsmalloc/zbud happy in future.

I doubt that but I'll answer in this thread:
https://lkml.org/lkml/2015/9/15/33 as zsmalloc deficiencies do not
have direct relation to this particular patch.

> Also, please keep it in mind that zram has been in linux kernel for
> memory efficiency for a long time and later zswap/zbud was born
> for *determinism* at the cost of memory efficiency.

Yep, and determinism is more important to me than the memory
efficiency. Dropping the compression ration from 3.2x to 1.8x is okay
with me and stalls in UI are not.

~vitaly

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