On Thu, 2020-03-05 at 12:41 -0800, Shakeel Butt wrote: > Have you actually seen this issue (i.e. JIT code reclaimed and > thrashing) happening for real workloads? The mention of gnome-shell wasn't entirely an accident, it's largely written in javascript which is jit-compiled. Under sufficiently dire disk I/O conditions merely moving the cursor would lag. That ought to be impossible, because nothing in the cursor update path ought to be blocking on the disk and we believe the CPU scheduler to be competent. Plenty of bugs are contributing here, but among them yes the (jitted bits of the) cursor update code can get paged out while megabytes of file-backed text stay resident. It's certainly drowned out by the contribution of the plenty of other bugs involved, but still. > Originally this heuristic was added to protect executable file pages > from the streaming workloads. Now we have workingset detection for > file pages and there is ongoing work for adding that support for anon > pages, I am wondering if this specific heuristic is still helpful. Enh. I would tend to think that code is way more precious than data in terms of staying resident. If the working set detection works well enough to come to that conclusion on its own without explictly knowing about executable pages, that'd be awesome and I'd be entirely fine with removing even more of this heuristic. - ajax
