On Tue, 2026-04-28 at 04:56 +0530, Ritesh Harjani wrote: > > > > I guess you missed answering this. The reason why I was asking about this > is.... >
Oops, sorry... > > > > baseline patched change > > > > buffered 1619.5 1611.2 -0.5% > > > > dontcache 1281.1 1629.4 +27.2% > > > > direct 1545.4 1609.4 +4.1% > > > > > > ... If we see the performace of buffered and dontcache in baseline case, > then we don't see dontcache doing any good. Even the patched version is > just slightly better compared to buffered case. > > But IIUC, dontcache should really shine in cases where we have buffered > writers dirtying the page cache pages which can overflow the RAM size > [1]. The reason why dontcache should show benefit there is, because we > don't see any page cache pressure, since after writeback the pages gets > evicted. Also earlier in the unpatched version, the I/O submission > happens immediately in the same context. > > So, I guess, isn't it better to evaluate those scenarios as well with > the patched version - since this series affects those code paths now? > > [1]: https://lore.kernel.org/all/[email protected]/ > > > Ok, that's a good point. I'll have Claude recreate a benchmark that mirrors what Jens did in the original posting and make sure the behavior of that test doesn't regress (at least not significantly). I'll try to get this done before LSF/MM, but we'll see. Cheers, -- Jeff Layton <[email protected]>
