Hello, On Wed, Sep 23, 2015 at 04:57:26PM -0500, Seth Jennings wrote: > On Wed, Sep 23, 2015 at 09:54:02AM +0200, Vitaly Wool wrote: > > On Wed, Sep 23, 2015 at 5:18 AM, Seth Jennings <sjennings@xxxxxxxxxxxxxx> wrote: > > > On Tue, Sep 22, 2015 at 02:17:33PM +0200, Vitaly Wool wrote: > > >> Currently zbud is only capable of allocating not more than > > >> PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE. This is okay as > > >> long as only zswap is using it, but other users of zbud may > > >> (and likely will) want to allocate up to PAGE_SIZE. This patch > > >> addresses that by skipping the creation of zbud internal > > >> structure in the beginning of an allocated page (such pages are > > >> then called 'headless'). > > > > > > I guess I'm having trouble with this. If you store a PAGE_SIZE > > > allocation in zbud, then the zpage can only have one allocation as there > > > is no room for a buddy. Sooooo... we have an allocator for that: the > > > page allocator. > > > > > > zbud doesn't support this by design because, if you are only storing one > > > allocation per page, you don't gain anything. > > > > > > This functionality creates many new edge cases for the code. > > > > > > What is this use case you envision? I think we need to discuss > > > whether the use case exists and if it justifies the added complexity. > > > > The use case is to use zram with zbud as allocator via the common > > zpool api. Sometimes determinism and better worst-case time are more > > important than high compression ratio. > > As far as I can see, I'm not the only one who wants this case > > supported in mainline. > > Ok, I can see that having the allocator backends for zpool > have the same set of constraints is nice. Sorry for delay. I'm on vacation until next week. It seems Seth was missed in previous discusstion which was not the end. 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 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 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. 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. Thanks. -- 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>