On Tue, Jul 7, 2026 at 2:47 PM Nhat Pham <[email protected]> wrote: > > On Tue, Jul 7, 2026 at 2:36 PM Yosry Ahmed <[email protected]> wrote: > > > > On Tue, Jul 7, 2026 at 2:35 PM Nhat Pham <[email protected]> wrote: > > > > > > On Tue, Jul 7, 2026 at 11:25 AM Yosry Ahmed <[email protected]> wrote: > > > > > > > > On Tue, Jul 7, 2026 at 2:38 AM Zenghui Yu <[email protected]> wrote: > > > > > > > > We were discussing a way for userspace to explicitly trigger a flush > > > > before, which would come in handy for testing. However, we decided not > > > > to expose flushing as a concept to userspace. > > > > > > > > Unfortunately I think the only way to "fix" the test is to allocate > > > > more memory, enough to trigger a flush on most interesting setups. > > > > Perhaps we should scale the amount of memory with the number of CPUs > > > > so that we don't have to keep playing whack-a-mole. > > > > > > I don't have a good idea for writeback, but for zswap out, would > > > MADV_PAGEOUT work here? > > > > I don't think the reclaim mechanism is the problem, but the fact that > > we don't have enough pending updates to flush the stats. Am I missing > > something? > > Ah yeah, you're right. Hmmm. > > Yeah it sucks, but maybe sleeping (more than the flush period) before > read is the only way. Which > is terribly implementation-dependent :(
I would honestly rather use more memory. I think there might be cases where the flusher is delayed. The flush being slightly delayed is not technically a bug that we want to see a failure for, but if a large stats change is not visible that's a user-noticeable behavior that we want a failure for. WDYT?
