On Fri, May 7, 2010 at 4:49 PM, Colin Walters <[email protected]> wrote: > On Fri, May 7, 2010 at 10:38 AM, Lennart Poettering <[email protected]> wrote: >> oom_adj is a way to make the OOM killer smarter. So far only very few >> apps set that, but we certainly could change that. > I think asking application authors to patch their apps to use that > interface is a lot less nice than say asking them to add this key, and > then if we decided that using the extant oom_adj kernel interface was > the way to go, the desktop UI could set oom_adj when launching the app > (after fork, before exec if it's inherited, otherwise take the small > race condition and set it after invocation).
I'd say "write a gtk loadable module". >> Hmm, I am not aware that on Linux we have anything like a low-memory >> signal. Please enlighten me on that! > We don't right now. There is no such thing as "low memory". Ideally you should have 100% of the memory used at all times. For apps, their data, their buffers, disk buffers etc. You know you're low on memory when your malloc fails. Failing a malloc of 500M is not the same as failing a malloc of 4K. Kernel knows it's low on memory when it badly needs to allocate but there is not enough memory. It then goes berserk and kills apps. >> So tell me, why exactly do you want this to be duplicated in userspace? > We can work out the exact details of how all the components interact > after the fact. Asking a userspace app to do anything when allocating 1 byte of memory is likely to fail is a more polite way of just harvesting it with the OOM killer. Also, with multiple users logged in, which app should we ask? -- Patryk Zawadzki _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
