On Thu, Oct 19, 2023 at 10:34 AM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > On Thu, Oct 19, 2023 at 10:12 AM Andrew Morton > <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, 17 Oct 2023 16:21:47 -0700 Nhat Pham <nphamcs@xxxxxxxxx> wrote: > > > > > Subject: [PATCH v3 0/5] workload-specific and memory pressure-driven zswap writeback > > > > We're at -rc6 and I'd prefer to drop this series from mm.git, have > > another go during the next cycle. > > > > However Hugh's v2 series "mempolicy: cleanups leading to NUMA mpol > > without vma" has syntactic dependencies on this series and will need > > rework, so I'd like to make that decision soon. > > > > Do we feel that this series can be made into a mergeable state within > > the next few days? > > There are parts of the code that I would feel more comfortable if > someone took a look at (which I mentioned in individual patches). So > unless this happens in the next few days I wouldn't say so. > I'm not super familiar with the other series. How big is the dependency? Looks like it's just a small part in the swapcache code right? If this is the case, I feel like the best course of action is to rebase the mempolicy patch series on top of mm-unstable, and resolve this merge conflict. I will then send out v4 of the zswap shrinker, rebased on top of the mempolicy patch series. If this is not the case, one thing we can do is: a) Fix bugs (there's one kernel test robot it seems) b) Fix user-visible details (writeback counter for e.g) and just merge the series for now. FWIW, this is an optional feature and disabled by default. So performance optimization and aesthetics change (list_lru_add() renaming etc.) can wait. We can push out v4 by the end of today and early tomorrow if all goes well. Then everyone can review and comment on it. How does everyone feel about this strategy? > > > > Thanks.
