From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932128AbbIWV5c (ORCPT ); Wed, 23 Sep 2015 17:57:32 -0400 Received: from smtp.variantweb.net ([104.131.104.118]:41787 "EHLO smtp.variantweb.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752633AbbIWV5a (ORCPT ); Wed, 23 Sep 2015 17:57:30 -0400 Date: Wed, 23 Sep 2015 16:57:26 -0500 From: Seth Jennings To: Vitaly Wool Cc: Dan Streetman , Andrew Morton , Minchan Kim , Sergey Senozhatsky , linux-kernel , Linux-MM Subject: Re: [PATCH v2] zbud: allow up to PAGE_SIZE allocations Message-ID: <20150923215726.GA17171@cerebellum.local.variantweb.net> References: <20150922141733.d7d97f59f207d0655c3b881d@gmail.com> <20150923031845.GA31207@cerebellum.local.variantweb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 23, 2015 at 09:54:02AM +0200, Vitaly Wool wrote: > On Wed, Sep 23, 2015 at 5:18 AM, Seth Jennings 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. I'll look at your latest patch. Thanks, Seth > > > We are crossing a boundary into zsmalloc style complexity with storing > > stuff in the struct page, something I really didn't want to do in zbud. > > Well, the thing is we need PAGE_SIZE allocations supported to use zram > with zbud. I can of course add the code handling this in zpool but I > am quite sure doing that in zbud directly is a better idea. I'm very > keen on keeping the complexity down as much as possible though. > > > zbud is the simple one, zsmalloc is the complex one. I'd hate to have > > two complex ones :-/ > > Who am I to disagree :) Keeping zbud simple is my goal, too, but once > again, I'd really like it to support PAGE_SIZE allocations. And if it > doesn't, the whole zpool thing for it becomes useless, since there > will hardly be any zbud users other than zswap. > > ~vitaly