[rrss]

by "freezes", 'deeter72 almost certainly means that the user interface becomes unresponsive, which is not relevant for servers.

windows has policies that prioritize maintaining user interface and foreground app responsiveness.

[rrss]

see also:

https://lore.kernel.org/all/d9802b6a-949b-b327-c4a6-3dbca485...

https://lore.kernel.org/all/[e-mail]...

[atmosx]

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=macOS+

So? What’s the point here?

[rrss]

I linked threads on LKML that are directly relevant to this subject, about how this (system becomes nonresponsive under memory pressure) is a real problem that people really experience, with a lot of people agreeing that it is a problem and suggesting various mitigations. Most of those ideas presuppose that memory pressure leads to stalls and are about figuring out how to detect when the system is stalled and making no progress and killing processes after it has gone on for a while (often with userspace daemons). I think MGLRU is maybe getting merged in linux 6.x and will hopefully help avoid the stalls.

you linked a list of all CVEs in macOS. I don't see how this is relevant at all.

[atmosx]

> [...] is a real problem that people really experience, with a lot of people agreeing that it is a problem and suggesting various mitigations [...]

tl;dr: I believe you are overblowing the importance of the bugs. In the bigger scheme of things they're more likely inconsequential.

(see my other reply for more)

[rrss]

These links are not just two simple bugs.

The first link is a report that the system becomes nonresponsive under memory pressure and a discussion of that report. In that thread, there was not really any agreement about whether this was a bug, let alone what the bug was, or what the fix would be.

The second wasn’t a bug at all, it was a patch proposed set of knobs to allow users to avoid the problem.

[ivlad]

I vaguely remember Solaris had a way to prioritise focused X Window application (IA) while keeping it within time-sharing (TS) scheduling class.

Kernel thread for interactive applications in focused window would then have higher priority than background applications improving responsiveness. I am not sure what manipulated the priority, but I assume Xsun (X Window server) did it.

[worthless-trash]

I believe that this absolutely could be done with ebpf setting schedule priority. A small daemon looking at the front-running window and you're there.

https://lwn.net/Articles/873244/

[atmosx]

I guessed as much but I stand by my statement… If there was a serious problem, we would know by now.

[rrss]

We do know by now, which is why the LKML thread I linked is titled "the elephant in the room."

[atmosx]

original answer:

Ok. I got it. Literally speaking there are two (maybe more?) known bugs. Do we know how many are there for Windows and macOS? I get freezes every now and then under macOS, so there _might_ be memory management issues there as well.

My point stills stands because I believe that the bugs you posted are largely inconsequential. Bugs could be very well been patched by now (or not). My guess the fix won't uptick the % of linux in desktop or server market.

IMHO "the truth is in the pudding": if the largest share of mobile OS's is based on linux (android) and largest % in servers in again based on linux, memory management is overall good enough - otherwise the market share would have dropped considerably.

UPDATE: Revisiting the thread question... I'm barking at the wrong tree. The question wasn't about relevance and market %. Your comment is to the point.

[rrss]

> if the largest share of mobile OS's is based on linux (android)

Android has had a variety of downstream patches over the last 5-10 years to address this problem. ChromeOS too.