lkml.org 
[lkml]   [2022]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv4 0/9] zsmalloc/zram: configurable zspage size
    On (22/11/11 09:03), Minchan Kim wrote:
    [..]
    > for class in classes:
    > wasted_bytes += class->pages_per_zspage * PAGE_SIZE - an object size
    >
    > with *aggressive zpage compaction*. Now, we are relying on shrinker
    > (it might be already enough) to trigger but we could change the policy
    > wasted memory in the class size crossed a threshold

    Compaction does something good only when we can release zspage in the
    end. Otherwise we just hold the global pool->lock (assuming that we
    land zsmalloc writeback series) and simply move objects around zspages.
    So ability to limit zspage chain size still can be valuable, on another
    level, as a measure to reduce dependency on compaction success.

    We may be can make compaction slightly more successful. For instance,
    if we would start move objects not only within zspages of the same size
    class, but, for example, move objects to class size + X (upper size
    classes). As an example, when all zspages in class are almost full,
    but class size + 1 has almost empty pages. In other words sort of as
    is those classes had been merged. (virtual merge). Single pool->look
    would be handy for it.

    But this is more of a research project (intern project?), with unclear
    outcome and ETA. I think in the mean time we can let people start
    experimenting with various zspage chain sizes so that may be at some
    point we can arrive to a new "default" value for all zspool, higher
    than current 4, which has been around for many years. Can't think, at
    present, of a better way forward.

    \
     
     \ /
      Last update: 2022-11-15 07:02    [W:2.827 / U:0.512 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site