On Thu, Apr 14, 2016 at 10:48 AM, Vlastimil Babka <vbabka@suse.cz> wrote:

> On 04/14/2016 10:05 AM, Vitaly Wool wrote:
>
>> This patch introduces z3fold, a special purpose allocator for storing
>> compressed pages. It is designed to store up to three compressed pages per
>> physical page. It is a ZBUD derivative which allows for higher compression
>> ratio keeping the simplicity and determinism of its predecessor.
>>
>
> So the obvious question is, why a separate allocator and not extend zbud?
>

Well, as far as I recall Seth was very much for keeping zbud as simple as
possible. I am fine either way but if we have zpool API, why not have
another zpool API user?


> I didn't study the code, nor notice a design/algorithm overview doc, but
> it seems z3fold keeps the idea of one compressed page at the beginning, one
> at the end of page frame, but it adds another one in the middle? Also how
> is the buddy-matching done?
>

Basically yes. There is 'start_middle' variable which point to the start of
the middle page, if any. The matching is done basing on the buddy number.

~vitaly