GNOME's GLib Adds GMemoryMonitor As Another Step In Helping Cope With Linux RAM Pressure

[phoronix]

Phoronix: GNOME's GLib Adds GMemoryMonitor As Another Step In Helping Cope With Linux RAM Pressure

With the new GNOME GLib 2.63.3 library release is a new "GMemoryMonitor" API for allowing notifications of when an application should attempt to free any non-critical system memory in an effort to help the system cope with memory pressure...

http://www.phoronix.com/scan.php?page=news_item&px=GNOME-GLib-GMemoryMonitor

[blacknova]

Damn, why just not write applications which assume that memory allocation is always successful?

[ElectricPrism]

Seems like aftermath of trying to save pennies on dollars. I think it's pretty obvious minimizing resource usage was never part of the original scope or goals of Gnome 3.x

[ssokolow]

What was old is new again. This reminds me of the Windows 3.1 memory allocation APIs.

[ferry]

Damn, why just not write applications which assume that memory allocation is always successful?

The problem with virtual memory that the allocation is indeed successful. However when accessing the memory (depending on the use) the associated disk io can bring the execution of all running tasks to almost a halt.

It is easy to trigger too. If you have like 4GB real RAM, open the linux kernel tree in Qgit (not even a gnome application) and scroll down a bit. Then get ready to push the hard reset button.

Imho i would be easy to mitigate too: substantially reducing the amount of cpu time allocated to the misbehaving task will stop the disk io and allow the remaining task to execute fine. But for some reason kernel devs don't want to make the cpu scheduler depend on memory usage.

[Candy]

GNOME never had a GLib!

glib, from my knowledge, has always been part (or pair) of (with) Gtk+ and GNOME depended on Gtk+.

So why do we change history and make glib and Gtk+ as something GNOME centric, when history tells us, that this has never been the case.

Gtk+ and glib has been invented because The GIMP (in its first couple of releases) depended on Motif. Later on The GIMP developers developed Gtk+ as free Toolkit for their imaging programm. Later on de Icaza and Co. build tools around the Gtk+ toolkit forming G.N.O.M.E. (yes with dots) around it.

Even if now Red Hat employees (and formerly GNOME centric developers) do work on Gtk3/4 still doesn't change the history and facts about Gtk+

[blacknova]

The problem with virtual memory that the allocation is indeed successful. However when accessing the memory (depending on the use) the associated disk io can bring the execution of all running tasks to almost a halt.

It is easy to trigger too. If you have like 4GB real RAM, open the linux kernel tree in Qgit (not even a gnome application) and scroll down a bit. Then get ready to push the hard reset button.

Imho i would be easy to mitigate too: substantially reducing the amount of cpu time allocated to the misbehaving task will stop the disk io and allow the remaining task to execute fine. But for some reason kernel devs don't want to make the cpu scheduler depend on memory usage.

Sorry, not native english speaker, so I might've said it wrong.
What I wanted to say is that application should not assume that memory allocation is always successful.

VM indeed ensure that memory allocation is successful in most cases but by nature have no guarantees of performance. OTH this process is transparent to applications right now as VM is handled in kernel space. But it is kernel which is ultimately decide if it can or cannot alloc memory for process. Right now it is possible for kernel to alloc memory and OOM killer to kill some process for that. It is possible that killed process is not the process which caused OOM and that is nuts.

[starshipeleven]

GNOME never had a GLib!

Now it does, the future is now, old man.

[starshipeleven]

It is possible that killed process is not the process which caused OOM and that is nuts.

It's nuts to kill important processes instead of non-critical ones in an OOM situation.

[blacknova]

It's nuts to kill important processes instead of non-critical ones in an OOM situation.

And what is import and not important? On server it is at least predictable and can be set by adjusting OOM score, on desktop or workstation it is much less. No, I'd stand by mine opinion, offending application should fail by itself, it should gracefully handle OOM situation and either shutdown or free unimportant memory usage (caches/etc) and attempt allocation again.