On Thu 28-04-16 21:40:48, Vitaly Wool wrote: > On Thu, Apr 28, 2016 at 1:58 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > On Thu 28-04-16 13:35:45, Vitaly Wool wrote: [...] > >> * zbud is 30% less object code > > > > This sounds like a lot but in fact: > > text data bss dec hex filename > > 2063 104 8 2175 87f mm/zbud.o > > 3467 104 8 3579 dfb mm/z3fold.o > > I get significantly larger code on an ARM64 machine... That is quite unexpected. I would assume that the arch specific growth would be proportional for both modules. [...] > >> * zbud exports its own API while z3fold is designed to work via zpool > > > > $ git grep EXPORT mm/zbud.c include/linux/zbud.h > > $ > > > > So the API can be used only from the kernel, right? I haven't checked > > users but why does the API actually matters. > > > > Or is there any other API I have missed. > > Not sure really. zswap used to call zbud functions directly rather > than via zpool. z3fold was only intended to be used via zpool. That of > course may be changed, but I consider it right to have something > proven and working side-by-side with the new stuff and if the new > stuff supersedes the old one, well, we can remove the latter later. On the other hand it is more code to maintain. I can see a reason to have more implementations if they are not overlapping completely - e.g. because they behave really differently for specific usecases which are too hard to be covered by a single algorithm. Is this the case here? If yes this should be really explained and justified. I really hate how all the Z* stuff is hard to grasp because there are way too many components already - each suited for a particular workload not considering others. I would hope for a simplification in that area rather than yet another option on top. Now, I might be just unfair here because I am not deeply familiar with Z* stuff but just looking at the configuration space makes my head hurt. > >> * limiting the amount of zpool users doesn't make much sense to me, > >> after all :) > > > > I am not sure I understand this part. Could you be more specific? > > Well, the thought was trivial: if there is an API which provides > abstraction for compressed objects storage, why not have several users > of it rather than 1,5? Because the configuration space is already too complicated and poor user has to decide what to use somehow. I would be completely lost on what to use now... From a first thought I would rather go with a better comprimation but is there any risk that I would end up using much more CPU for that or that I might be just too unlucky and my data wouldn't compress enough to fit in? > What we need to do is to provide a better > documentation (I must admit I wasn't that good in doing this) on when > to use what. That would be certainly appreciated. Thanks! -- Michal Hocko SUSE Labs -- 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>