On Fri, Jan 25, 2008 at 01:08:09AM +0200, Adrian Bunk wrote:I agree, it's only a few processes where this makes sense. But for those that do, it would be useful if they could register with the kernel that would like to know, (just before the system starts ejecting cached data, just before swapping, etc.) and at what frequency. And presumably, if the kernel notices that a process is responding to such requests with memory actually getting released back to the system, that process could get "rewarded" by having the OOM killer less likely to target that particular thread. AIX basically did this with SIGDANGER (the signal is ignored by default), except there wasn't the ability for the process to tell the kernel at what level of memory pressure before it should start getting notified, and there was no way for the kernel to tell how bad the memory pressure actually was. On the other hand, it was a relatively simple design. In practice very few processes would indeed pay attention to SIGDANGER, so I think you're quite right there. Absolutely. - Ted --
| Jon Smirl | 463 kernel developers missing! |
| Nigel Cunningham | Re: [PATCH] Remove process freezer from suspend to RAM pathway |
| Greg KH | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scan... |
| Jeff Garzik | Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series.. |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Linus Torvalds | Re: [GIT]: Networking |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
