Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux 7.3 improves performance when running out of vRAM

pixelcluster.dev

Post reply on HN
Print view View original

311–320 of 328 posts

Re: Linux 7.3 improves performance when running out of vRAM

#311

Post by hnlmorg »

pjmlp wrote: post #306
hnlmorg wrote: post #262

Earlier quoted context omitted.

macOS includes a GUI user land whereas Linux is just a kernel. So Apple can build a whole user-controlled GUI workflow around memory exceptions, which Linux cannot. Maybe what needs to happen is new Linux syscalls + signals for DEs to utilise for building memory exception UIs? But the problem then with that is you’re impacting the portability of those DEs. So some maintainers might still refuse to work with Linux to…

I mentioned they aren't the only UNIX where this isn't a problem. Also we cannot use the reasoning Linux means distributions, instead of using GNU/Linux for it, and other times Linux is just the kernel, depending on convenience.

> I mentioned they aren't the only UNIX where this isn't a problem.

You did. But without examples, it’s a meaningless throwaway.

Personally, I can’t say I’ve pushed many other UNIX desktops that far that they’ve OOMed. Except maybe OpenSolaris and FreeBSD, neither of which faired much better. But they’d also suffer from the same kind of DE development issues I described for Linux.

> Also we cannot use the reasoning Linux means distributions, instead of using GNU/Linux for it, and other times Linux is just the kernel, depending on convenience.

I’m not saying it for convenience. I’m saying it because it matters in this specific situation.

Surely you must understand that the reason Windows and macOS have arguably better GUI support for OOM is because the same company that owns the kernel also writes the frontend too? It’s hardly rocket science as a concept.

As I said in my previous comment, there are ways Linux (the kernel) could work with DEs to bridge that gap. But at present, they’re entirely separate concerns.

Re: Linux 7.3 improves performance when running out of vRAM

#312

Post by hnlmorg »

jamesfinlayson wrote: post #288
hnlmorg wrote: post #256

Earlier quoted context omitted.

I get memory related freezes on macOS all the time. And back when I was forced into running Windows, I used to get memory-related freezes daily. Literally daily. So I’m really not convinced the situation is drastically different there. I mean if it were that simple, Linux would have fixed it already.

Yeah I got MacOS freezes sometimes - never checked Activity Monitor to see why though. On Windows it's usually the hard drive being over-used that makes things drag for me.

Yeah, Windows file system backend is highly object oriented and has a bunch of event driven hooks. Which is great for supporting tools like antivirus. But terrible for lots of small random writes (on area Linux and most UNIX systems excel at).

Re: Linux 7.3 improves performance when running out of vRAM

#314

Post by pjmlp »

hnlmorg wrote: post #311
pjmlp wrote: post #306

Earlier quoted context omitted.

I mentioned they aren't the only UNIX where this isn't a problem. Also we cannot use the reasoning Linux means distributions, instead of using GNU/Linux for it, and other times Linux is just the kernel, depending on convenience.

> I mentioned they aren't the only UNIX where this isn't a problem. You did. But without examples, it’s a meaningless throwaway. Personally, I can’t say I’ve pushed many other UNIX desktops that far that they’ve OOMed. Except maybe OpenSolaris and FreeBSD, neither of which faired much better. But they’d also suffer from the same kind of DE development issues I described for Linux. > Also we cannot use the reasoning L…

Who says it needs to be desktop for proper memory management, servers and embedded can crash willy-nilly with OOM?

In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP.

Re: Linux 7.3 improves performance when running out of vRAM

#315

Post by zahlman »

exceptione wrote: post #14

Great article! I share the same hunch as the author does; when allocating memory ultimately the application itself is in the best position to inform the kernel about the desired stickiness to VRAM. The best a kernel can do is guessing . As a side note, it strikes me how much we owe to young trans people for low level performance engineering.

Can someone please explain to me why it is apparently off-topic to point out that someone is bringing up irrelevant issues of gender identity, but not off-topic to do so in the first place?

Re: Linux 7.3 improves performance when running out of vRAM

#316

Post by zahlman »

exceptione wrote: post #217
zahlman wrote: post #192

Earlier quoted context omitted.

[flagged]

> you intend to provoke Indeed, I made a small friendly side note to provoke you. Sir/madam, I sincerely think your reasoning is a bit off here, but if you feel you have been done wrong by me, please inform the admins. For the rest, please go back on topic.

Has it occurred to you how this line of argument would sound if the original comment had been about a socially-deemed "privileged" group instead?

Do you understand that the nature of the group is actually completely irrelevant to my criticism?

Do you see why you would be perceived as being the one who went off topic in the first place?

Re: Linux 7.3 improves performance when running out of vRAM

#317

Post by hnlmorg »

pjmlp wrote: post #314
hnlmorg wrote: post #311

Earlier quoted context omitted.

> I mentioned they aren't the only UNIX where this isn't a problem. You did. But without examples, it’s a meaningless throwaway. Personally, I can’t say I’ve pushed many other UNIX desktops that far that they’ve OOMed. Except maybe OpenSolaris and FreeBSD, neither of which faired much better. But they’d also suffer from the same kind of DE development issues I described for Linux. > Also we cannot use the reasoning L…

Who says it needs to be desktop for proper memory management, servers and embedded can crash willy-nilly with OOM? In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP.

> Who says it needs to be desktop for proper memory management, servers and embedded can crash willy-nilly with OOM?

The context of the thread is about the UX.

And the OS crashing isn’t a better option than an OOM killer. Frankly, there’s no good automated options. That’s why modern desktop OSs present users with a warning. And hence why we are talking about GUIs.

> In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP.

Listing OSs doesn’t explain how they handle things better.

For example you’ve cited SunOS and I already said previously, I’ve seen SunOS completely die on its arse when OOM.

Re: Linux 7.3 improves performance when running out of vRAM

#318

Post by vladvasiliu »

plingbang wrote: post #220
vladvasiliu wrote: post #70

Earlier quoted context omitted.

I don't use windows too often, but I remember I was happy with an update a year or two ago which allows changing the volume by scrolling on the tray icon. Now, of course, it still doesn't work with a touchpad, but baby steps, right?

This feature has been was available on GNOME since forever. I'm still waiting for Microsoft to steal another nice thing: MRU (Most Recently Used) keyboard layout switching. If you have two often used keyboard layouts A and B, and less used layouts C, D, E, then pressing the switch shortcut once will switch between A and B without the need to cycle through C, D, E.

I never really cared for Gnome so I've never actually used it, but I can't say I'm surprised.

But this has worked in KDE since version 3, like, 20 years ago? And also with pasystray running under i3, since before win11 was a thing. They both support scrolling with the touchpad, too.

It drove me up a wall not being able to do this when I had to use Windows at work.

As for your MRU layout thing, I'm not sure I'd like it. While I like MRU for alt-tab, i like my not-so-often-used functions to be predictable. For this specific case, I always use us-macintosh, so I'd like to be sure that if I press the shortcut X times I'll get Y layout, without having to remember the order in which I used them. Now, to be fair, in my case I only have US-Mac available since it does everything I need.

Re: Linux 7.3 improves performance when running out of vRAM

#319

Post by da_chicken »

wahern wrote: post #172
da_chicken wrote: post #162

Earlier quoted context omitted.

Windows does freeze and become unstable, but it's usually because of some ring 0 errors not getting trapped appropriately. But Windows has always handled both OOM and out of disk space very well. The system will be extremely sluggish, but it typically continues operating. The Linux design is to keep using memory, then push to swap, and then when you OOM you hard lock. The built in kernel OOM module can miss when RAM…

Doesn't Windows, like macOS, automatically expand swap? You can't run out of memory nearly as quickly as you can on Linux. And at least on Windows I always figured this is why it felt so sluggish under load--it ends up paging alot. Not sure why macOS has always felt more consistent; perhaps the OS and major apps are less gratuitous memory hogs?

In Windows 9x (95/98/ME) the swap file could expand indefinitely, with no mechanism to limit its size.

Under Windows NT 4.0, Win2k, or WinXP and on, the page file has a built-in size limit that you can set. You can indirectly force that minimum size to increase if you enable full memory dump capture in the event of a crash (it must be larger than main memory to do that) and that was really easy to do so I think a lot of people made that mistake. Even on the modern Windows, if you have a crash then the system will automatically enable full memory dumps for the next 4 weeks hoping to be able to debug the second crash. That can also result in the minimum size increasing beyond the maximum you set, but in neither case does it grow indefinitely.

Eventually the OS will start returning an error that it's out of memory or out of virtual memory. But if the application you're running can handle that gracefully, then it may not even crash.

I think Windows is sluggish now in part because it's about 5 or 6 layers of abstractions piled on top of each other between the application and the hardware, and also because Microsoft keeps jamming services and side projects onto you. It's been a long time since Microsoft has adopted the "shut up and get out of the user's way" approach to OS design. Now it loves to distract you from the program you're working in.

Re: Linux 7.3 improves performance when running out of vRAM

#320

Post by Espressosaurus »

hnlmorg wrote: post #317
pjmlp wrote: post #314

Earlier quoted context omitted.

Who says it needs to be desktop for proper memory management, servers and embedded can crash willy-nilly with OOM? In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-UX, z/OS UNIX, NeXTSTEP.

> Who says it needs to be desktop for proper memory management, servers and embedded can crash willy-nilly with OOM? The context of the thread is about the UX. And the OS crashing isn’t a better option than an OOM killer. Frankly, there’s no good automated options. That’s why modern desktop OSs present users with a warning. And hence why we are talking about GUIs. > In any case, Xenix, DG/UX, SunOS/Solaris, Aix, HP-U…

Allowing allocations to fail is a solution.

Alas, not one that was made back in 1970, so here we are.

Post reply on HN