Hi,
AIX contains the SIGDANGER signal to notify applications to free up some
unused cached memory:
http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html
There have been a few discussions on implementing such an idea on Linux,
but nothing concrete has been achieved.
On the kernel side Rik suggested two notification points: "about to
swap" (for desktop scenarios) and "about to OOM" (for embedded-like
scenarios).
With that assumption in mind it would be necessary to either have two
special devices for notification, or somehow indicate both events
through the same file descriptor.
Comments are more than welcome.
On 10/18/2007 10:25 PM, Marcelo Tosatti wrote:
> AIX contains the SIGDANGER signal to notify applications to free up some
> unused cached memory:
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html
>
> There have been a few discussions on implementing such an idea on Linux,
> but nothing concrete has been achieved.
>
> On the kernel side Rik suggested two notification points: "about to
> swap" (for desktop scenarios) and "about to OOM" (for embedded-like
> scenarios).
>
> With that assumption in mind it would be necessary to either have two
> special devices for notification, or somehow indicate both events
> through the same file descriptor.
>
> Comments are more than welcome.
Given the desktop/embedded distinction you made, do you need both scenarios
active at the same time? If not, it seems something like a
echo -n <level> >/proc/sys/vm/danger
could do with just one sigdanger notification point? (with <level> suitably
defined as or in terms of the used threshold value).
Rene.
On Thu, 18 Oct 2007 22:38:21 +0200
Rene Herman <[email protected]> wrote:
> On 10/18/2007 10:25 PM, Marcelo Tosatti wrote:
>
> > AIX contains the SIGDANGER signal to notify applications to free up
> > some unused cached memory:
> >
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html
> >
> > There have been a few discussions on implementing such an idea on
> > Linux, but nothing concrete has been achieved.
> >
> > On the kernel side Rik suggested two notification points: "about to
> > swap" (for desktop scenarios) and "about to OOM" (for embedded-like
> > scenarios).
> >
> > With that assumption in mind it would be necessary to either have
> > two special devices for notification, or somehow indicate both
> > events through the same file descriptor.
> >
> > Comments are more than welcome.
>
> Given the desktop/embedded distinction you made, do you need both
> scenarios active at the same time? If not, it seems something like a
>
> echo -n <level> >/proc/sys/vm/danger
>
> could do with just one sigdanger notification point? (with <level>
> suitably defined as or in terms of the used threshold value).
If you do that, how are applications to know which of the two
scenarios is happening when they get a signal?
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
On 10/18/2007 10:52 PM, Rik van Riel wrote:
> On Thu, 18 Oct 2007 22:38:21 +0200
> Rene Herman <[email protected]> wrote:
>
>> On 10/18/2007 10:25 PM, Marcelo Tosatti wrote:
>>
>>> AIX contains the SIGDANGER signal to notify applications to free up
>>> some unused cached memory:
>>>
>>> http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html
>>>
>>> There have been a few discussions on implementing such an idea on
>>> Linux, but nothing concrete has been achieved.
>>>
>>> On the kernel side Rik suggested two notification points: "about to
>>> swap" (for desktop scenarios) and "about to OOM" (for embedded-like
>>> scenarios).
>>>
>>> With that assumption in mind it would be necessary to either have
>>> two special devices for notification, or somehow indicate both
>>> events through the same file descriptor.
>>>
>>> Comments are more than welcome.
>> Given the desktop/embedded distinction you made, do you need both
>> scenarios active at the same time? If not, it seems something like a
>>
>> echo -n <level> >/proc/sys/vm/danger
>>
>> could do with just one sigdanger notification point? (with <level>
>> suitably defined as or in terms of the used threshold value).
>
> If you do that, how are applications to know which of the two
> scenarios is happening when they get a signal?
They don't -- that's why I asked if you need both scenario's active at the
same time. SIGDANGER would just be SIGPLEASEFREEALLYOUCAN with the operator
deciding through setting the level at which point applications get it.
Or put differently; what's the additional value of notifying an application
that the system is about to go balistic when you've already asked it to free
all it could earlier? SIGSEEDAMNITITOLDYOUSO?
Don't get me wrong; never saw this discussion earlier, may be sensible...
Rene.
On Thu, 18 Oct 2007 23:06:52 +0200
Rene Herman <[email protected]> wrote:
> They don't -- that's why I asked if you need both scenario's active
> at the same time. SIGDANGER would just be SIGPLEASEFREEALLYOUCAN with
> the operator deciding through setting the level at which point
> applications get it.
>
> Or put differently; what's the additional value of notifying an
> application that the system is about to go balistic when you've
> already asked it to free all it could earlier? SIGSEEDAMNITITOLDYOUSO?
The first threshold - "we are about to swap" - means the application
frees memory that it can. Eg. free()d memory that glibc has not yet
given back to the kernel, or JVM running the garbage collector, or ...
The second threshold - "we are out of memory" - means that the first
approach has failed and the system needs to do something else. On an
embedded system, I would expect some application to exit or maybe
restart itself.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
On 10/18/2007 11:18 PM, Rik van Riel wrote:
> On Thu, 18 Oct 2007 23:06:52 +0200
> Rene Herman <[email protected]> wrote:
>
>> They don't -- that's why I asked if you need both scenario's active
>> at the same time. SIGDANGER would just be SIGPLEASEFREEALLYOUCAN with
>> the operator deciding through setting the level at which point
>> applications get it.
>>
>> Or put differently; what's the additional value of notifying an
>> application that the system is about to go balistic when you've
>> already asked it to free all it could earlier? SIGSEEDAMNITITOLDYOUSO?
>
> The first threshold - "we are about to swap" - means the application
> frees memory that it can. Eg. free()d memory that glibc has not yet
> given back to the kernel, or JVM running the garbage collector, or ...
>
> The second threshold - "we are out of memory" - means that the first
> approach has failed and the system needs to do something else. On an
> embedded system, I would expect some application to exit or maybe
> restart itself.
That first threshold sounds fine yes. To me, the second mostly sounds like a
job for SIGTERM though.
The OOM killer could after it selected the task for killing first try a TERM
on it to give a chance to exit gracefully and only when that doesn't help
make it eligible for killing on a second round through the badness calculation.
You could moreover _never_ make a task eligible for killing before it
received a SIGTERM, thereby guaranteeing that everyone got the SIGTERM
before killing anything, and it seems SIGTERM would be a more focussed
version of SIGDANGER2 then.
Would at least forego any need for multiplexing the DANGER signal.
Rene.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rene Herman wrote:
> That first threshold sounds fine yes. To me, the second mostly sounds
> like a job for SIGTERM though.
I agree. Applications shouldn't be expected to be yet more complicated
and have different levels of low memory handling. You might want to
give a process a second shot at handling SIGDANGER but after that's it's
all about preparation for a shutdown.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHF9m/2ijCOnn/RHQRAhwjAKC38y1OLv0mE5sWHY31CwJ2ZaoAXwCglDTO
05pmpe8jMVhwM0nlCHqZyaQ=
=5DvG
-----END PGP SIGNATURE-----
On 10/19/2007 12:01 AM, Rene Herman wrote:
> On 10/18/2007 11:18 PM, Rik van Riel wrote:
>
>> On Thu, 18 Oct 2007 23:06:52 +0200
>> Rene Herman <[email protected]> wrote:
>>
>>> They don't -- that's why I asked if you need both scenario's active
>>> at the same time. SIGDANGER would just be SIGPLEASEFREEALLYOUCAN with
>>> the operator deciding through setting the level at which point
>>> applications get it.
>>>
>>> Or put differently; what's the additional value of notifying an
>>> application that the system is about to go balistic when you've
>>> already asked it to free all it could earlier? SIGSEEDAMNITITOLDYOUSO?
>>
>> The first threshold - "we are about to swap" - means the application
>> frees memory that it can. Eg. free()d memory that glibc has not yet
>> given back to the kernel, or JVM running the garbage collector, or ...
>>
>> The second threshold - "we are out of memory" - means that the first
>> approach has failed and the system needs to do something else. On an
>> embedded system, I would expect some application to exit or maybe
>> restart itself.
>
> That first threshold sounds fine yes. To me, the second mostly sounds
> like a job for SIGTERM though.
>
> The OOM killer could after it selected the task for killing first try a
> TERM on it to give a chance to exit gracefully and only when that
> doesn't help make it eligible for killing on a second round through the
> badness calculation.
>
> You could moreover _never_ make a task eligible for killing before it
> received a SIGTERM, thereby guaranteeing that everyone got the SIGTERM
> before killing anything, and it seems SIGTERM would be a more focussed
> version of SIGDANGER2 then.
Well, no, that "guarantee" is fairly badly formulated but I mean "before
everyone got a SIGTERM" ofcourse. That is, first do the same selection as
now but don't send KILL but TERM and mark the task as having received a TERM
already and make it not eligible anymore. Only when there are no TERM
eligible tasks anymore, start sending KILL.
> Would at least forego any need for multiplexing the DANGER signal.
Rene.
Ulrich Drepper wrote:
> I agree. Applications shouldn't be expected to be yet more complicated
> and have different levels of low memory handling. You might want to
> give a process a second shot at handling SIGDANGER but after that's it's
> all about preparation for a shutdown.
I disagree. From an embedded viewpoint it would be nice to have a
"please free up memory", then a "we really need memory NOW", then
finally the kernel oom killer.
The advantage of the middle message is that it allows userspace to do
smarter things if it wants to (for instance, if there is an overall
system manager or some such thing, it could do a better job of
restarting tasks than the kernel oom killer since it knows the relative
importance of tasks).
Chris
On Thu 2007-10-18 15:10:07, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rene Herman wrote:
> > That first threshold sounds fine yes. To me, the second mostly sounds
> > like a job for SIGTERM though.
>
> I agree. Applications shouldn't be expected to be yet more complicated
> and have different levels of low memory handling. You might want to
> give a process a second shot at handling SIGDANGER but after that's it's
> all about preparation for a shutdown.
That works okay on a PC, but try cellphone one day.
You want management app to close the least used application. You do
not want _kernel_ to select "who to send SIGTERM to".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>>>>> "Pavel" == Pavel Machek <[email protected]> writes:
Pavel> That works okay on a PC, but try cellphone one day.
Pavel> You want management app to close the least used
Pavel> application. You do not want _kernel_ to select "who to send
Pavel> SIGTERM to".
That's why I would prefer that *all* processes receive the
SIGDANGER/whatever (and of course ignore it by default). Only the
management app would handle it in the case you describe and would
select one or more applications to unload to free some memory.
Sam
--
Samuel Tardieu -- [email protected] -- http://www.rfc1149.net/
Samuel Tardieu wrote:
>>>>>>"Pavel" == Pavel Machek <[email protected]> writes:
> Pavel> That works okay on a PC, but try cellphone one day.
>
> Pavel> You want management app to close the least used
> Pavel> application. You do not want _kernel_ to select "who to send
> Pavel> SIGTERM to".
>
> That's why I would prefer that *all* processes receive the
> SIGDANGER/whatever (and of course ignore it by default). Only the
> management app would handle it in the case you describe and would
> select one or more applications to unload to free some memory.
It's still helpful to have two stages...one that all apps can listen to
(and try to reduce their footprint if possible), and a second one that
only the manager would handle (and would kill some suitable target).
Finally, if all that fails then the kernel starts whacking things.
Chris