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, 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>