Desktop interactivity/IO latency test to bisect kernel bug introduced 2.6.16-19

It would be super helpful if someone could help me confirm this behaviour detoriation I noticed 17 years back around kernel 2.6.17. Subjectively, something with the I/O stack broke and never quite recovered. For that, please propose robust ways of testing interactivity / responsiveness under concurrent load. The goal is to use it for example with the well-known PTS to bisect the relevant kernel range. The inbuilt `phoronix-test-suite benchmark kernel` will only run a series of low-complexity scenarios that say very little about what happens under heavy multitasking load.

The test case should be stressing I/O paths as well as CPU and preferably induce swapping. How could this be automated reliably?

AI asstisted answers welcome.

Full story: I remember using Gentoo at the time and back around 2007, I was impressed by the extreme desktop fluidity even when compiling openoffice, watching a HD sat tv stream and skipping between applications and many browser tabs on a moderate machine.. Then came another fluke kernel update and since then, never had the experience again of a robustly smooth desktop experience even under heavy (swap!) load.. Nowadays, even on a 48GiB RAM xeon hexacore system, memory never seems to be enough and when the system is up for a few weeks, sluggishness accumulates even beyond Xorg / browser restarts. It is a mystery to me and I think linux can do much better.