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.
