OOM killers serve a purpose but - for a desktop OS - they're missing the point.

In a sane world the user would decide which application to shut down, not the OS; the user would click the appropriate application's close gadget, and the user interface would remain responsive enough for that to happen in a matter of seconds rather than minutes.

I understand the many reasons why that's not possible, but it's a huge failing of Linux as a desktop OS, and OOM killers are picking around the edges of the problem, not addressing it head-on.

(Which isn't to say, of course, that OOM killers aren't the right approach in a server context.)

This is effectively what macOS does. It presents any end user GUI programs (or Terminal.app if it's a CLI program) to elect to kill by way of popup with the amount of memory the application is consuming and whether or not it is responsive.

Not a bad system, but macOS has a fundamental memory leak for the past few versions which causes even simple apps like Preview.app, your favorite browser (doesn't matter which one), etc. to 'leak' and bring up the choose-your-own-OOM-kill-target dialog.

I don't even think it's not possible — surely there already exist solutions similar to BFS scheduler that would improve interactive performance

> I understand the many reasons why that's not possible

Isn't the only reason that the UI effectively freeze under high memory pressure? If the processing involved in the core parts of the UI could be prioritized there's no reason for it not to work?

I don't understand why we can't have (?) a way of saying "the pages of these few processes are holy"? (yes, it would still be slow allocating new pages, but it should be possible to write a small core part such that it doesn't need to constantly allocate memory?)