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

[Vitaly Wool]

On Fri, Sep 25, 2015 at 10:47 AM, Minchan Kim <minchan@xxxxxxxxxx> wrote:
> On Fri, Sep 25, 2015 at 10:17:54AM +0200, Vitaly Wool wrote:
>> <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.
>
> Yes, I don't want to interrupt zbud thing which is Seth should maintain
> and I respect his decision but the reason I nacked is you said this patch
> aims for supporing zbud into zsmalloc for determinism.
> For that, at least, you should discuss with me and Sergey but I feel
> you are ignoring our comments.
>
>>
>> > 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.
>
> No. If you want to contribute something, you should prove why yours
> is better. I already said my concerns and my approach. It's your turn
> that you should explain why it's better.

In fact, I do not add any specific functionality, my patches just do
what should have already been done -- that is, zram should have been
converted to use zpool api long ago. Your opposing to that is counter
productive.

>> > 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.
>
> Then, you could use zswap which have aimed for it with small changes
> to prevent writeback.

Should i come with a patch to zram explicitly stating that it is not
meant to be used in any environment that is deterministic / worst case
critical? Is that what you are aiming for?

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