On Tue, 3 Sep 2024 11:38:37 -0700 Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > [ 39.157954] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000007 > > [ 39.158288] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 > > [ 39.158634] R13: 0000000000002b9a R14: 0000000000000000 R15: 00007ffd619d5518 > > [ 39.158998] </TASK> > > [ 39.159226] ---[ end trace 0000000000000000 ]--- > > > > After reverting this or Usama's "mm: store zero pages to be swapped > > out in a bitmap", the problem is gone. I think these two patches may > > have some conflict that needs to be resolved. > > Yup. I saw this conflict coming and specifically asked for this > warning to be added in Usama's patch to catch it [1]. It served its > purpose. > > Usama's patch does not handle large folio swapin, because at the time > it was written we didn't have it. We expected Usama's series to land > sooner than this one, so the warning was to make sure that this series > handles large folio swapin in the zeromap code. Now that they are both > in mm-unstable, we are gonna have to figure this out. > > I suspect Usama's patches are closer to land so it's better to handle > this in this series, but I will leave it up to Usama and > Chuanhua/Barry to figure this out :) > > [1]https://lore.kernel.org/lkml/CAJD7tkbpXjg00CRSrXU_pbaHwEaW1b3k8AQgu8y2PAh7EkTOug@xxxxxxxxxxxxxx/ Thanks. To unbreak -next I'll drop the two-patch series "mm: Ignite large folios swap-in support" for now. btw, next time can we please call it "enable large folios swap-in support"? "ignite" doesn't make much sense here.
