Re: [linux-next:master] [mm] 7b32f64bc5: pts.svt-av1.Preset13.Bosphorus4K.frames_per_second 45.8% regression
Suren Baghdasaryan <[email protected]> Thu, 18 Jun 2026 16:03:43 +0000
| Newsgroups | dev.linux.lists.oe-lkp,org.kernel.vger.linux-fsdevel,org.kvack.linux-mm |
|---|---|
| Message-ID | <CAJuCfpFed0GuMk+dE-Xn0w45Mn1Spds-pc2BE__FUoWm6+R7_w@mail.gmail.com> |
On Thu, Jun 18, 2026 at 2:30=E2=80=AFPM Lorenzo Stoakes <[email protected]> wr= ote: > > On Thu, Jun 18, 2026 at 11:30:47AM +0200, Jan Kara wrote: > > On Thu 18-06-26 16:00:42, kernel test robot wrote: > > > Hello, > > > > > > kernel test robot noticed a 45.8% regression of pts.svt-av1.Preset13.= Bosphorus4K.frames_per_second on: > > > > This one looks serious enough and real. It would be good to figure out = what > > happens in this benchmark that it benefits from the readahead across VM= A > > boundaries so much... > > I think a revert first no? This seems pretty huge for something that isn'= t key > to the kernel, then a new attempt can be tried with this issue addressed > perhaps? A quick search yields: "The pts.svt-av1.Preset13.Bosphorus4K.frames_per_second is a benchmarking metric from the Phoronix Test Suite that measures how many frames per second a CPU can encode using the open-source SVT-AV1 video encoder." If this is a video encoding benchmark I would expect it to explicitly prefetch the data from the disk before measuring the encoding speed. If limiting readahead caused this regression, I suspect the benchmark doesn't explicitly prefetch the data... > > I seem to recall objecting to this in the past, had a look around and saw= [0] > which has some discussion I think specifically on the VMA boundaries thin= g. > > [0]:https://lore.kernel.org/linux-mm/CAC_TJvfG8GcwG_2w1o6GOTZS8tfEx2h9A91= [email protected]/ > > (Sorry to be naggy buuut :) - I see there wasn't maintainer [Matthew] sig= noff on > this, we should really be in the habit of _requiring_ that for merge). > > Thanks, Lorenzo