linux-kernel - Re: [External] Re: [PATCH v2] zswap: add writeback_time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACSyD1MxxhAGFQL4aq7DKNdROdtOs1Mj6R-EsxbPfr=JdVEzeg@mail.gmail.com>
Date:   Mon, 30 Oct 2023 11:34:11 +0800
From:   贺中坤 <hezhongkun.hzk@...edance.com>
To:     Nhat Pham <nphamcs@...il.com>
Cc:     akpm@...ux-foundation.org, hannes@...xchg.org,
        yosryahmed@...gle.com, sjenning@...hat.com, ddstreet@...e.org,
        vitaly.wool@...sulko.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [External] Re: [PATCH v2] zswap: add writeback_time_threshold
 interface to shrink zswap pool

Hi  Nhat， thanks for your time.

> My original concern with this approach (i.e regarding what value should be
> used, and how frequent should userspace trigger this time-based writeback
> mechanism) still stands.
>
> If I'm a user of this feature, how would I figure out how long should an object
> lie dormant in the zswap pool before it is highly likely to be a cold object?
> Users have no clue what the access time stats look like, what is its
> distribution,
> etc., and will have to somehow guesstimate this based purely on their knowledge
> of the program's memory access patterns (which, in many cases, are intentionally
> abstracted away).
>
> It's rather hard for users to know what value of cutoff makes sense, without
> extensive experiments on a realistic workload.

I understand your concern, and it is indeed a problem. There are
currently too few
contexts in which this feature is used, and determining the threshold
is very difficult.
So I have a new idea to show the lie dormant time distribution through
a new patch,
as you mentioned above.Based on this time distribution, users can make better
choices.

>
> If I may ask, how do you use this feature internally? You don't have to
> reveal any NDA-breaking details of course, but just a rough idea of
> the kind of procedure to determine sensible threshold values will
> help your case and the future user of this feature a lot.
>

As you mentioned, we decide this threshold based on the knowledge of the
program's memory access patterns and the multiple test results for different
business models，just an experience value.
So  the patch to show the lie dormant time distribution should be valuable.

>
> nit: looks there's a double space between time and will?
>

Oh, got it, thanks.

> > +
> > +          The zswap can be swapout and save memory in userspace proactively
> > +          by writing writeback_time_threshold in second.
>
> I think we should include a bit more details in this config option description.
> Feel free to just recycle details from the commit log of course, but at least
> there should be something along the line of:
>
> When this is selected, users can proactively trigger writebacks by writing a
> value to the writeback_time_threshold file. The pages whose last access time
> is older than this value will be written back.
>
> (please beautify that paragraph if you use it).
>

Thanks  a lot for your description. I will add it.

>
> Do you have any experimental results/benchmarks that show
> the wins from this approach?

OK,  Add it for next time.
>
> Writing back cold pages from zswap is a good idea from a
> theoretical and philosophical POV, but all sort of things could go
> wrong, especially if we write pages that turn out to be needed
> later on. Some experimental results would be nice.

Thanks, i will add a new patch to show the last acccesed time distribution
and add experimental results.