>> > I have a program that keeps malloc()ing (and scribbling a bit
>> > into the allocated memory) until malloc() fails. The
>> > intention is to put pressure on the VM system to find out how
>> > much pool cache memory it can reclaim.
>> Such a program would be a prime candidate for declaring itself a
>> preferred out-of-swap victim.
> Well. First of all, such a program don't exist, as the malloc is not
> failing.
Strictly speaking, yes. I was talking about a program that satisfies
the intention, rather than the letter of the description. In this
case, something like "a program that keeps grabbing and touching memory
as long as it can, to provoke memory reclaims in the kernel", with its
death being due to out-of-swap rather than as a reaction to a failing
malloc.
>> It probably wouldn't be easy - the process which incurred the page
>> fault would have to be put to sleep pending the death of the victim
>> process - but it could provide for much better behaviour in
>> situations like this.
> Second - are you proposing that you'd keep some kind of statistics on
> mallocs done in the past in some way, in order to decide that this
> process should now be a candidate for a kill when you run out of
> pages?
No. Trying to do something "smart" with process behaviour history
strikes me as a disaster waiting to happen.
What I'm suggesting is that a program with the intent sketched above
should do something like
set_swap_kill_preference(1);
(or whatever the chosen API is - perhaps using sysctl?) in order to
indicate to the kernel that it is volunteering itself as a preferred
out-of-swap victim, even if it's not the process that incurs the
problematic page fault.
> Even more, how do we decide that it's actually malloc, or are any
> memory demand treated equally?
It's not truly malloc(); like most of this discussion, it's really
talking about a process that needs a new page to satisfy a write to a
COW or demand-zero page when there are no pages available.
To put it loosely, anything that could provoke an out-of-swap SIGKILL
from the kernel.
>> Perhaps even better would be a way for userland to tell the kernel
>> "pretend you're under severe RAM pressure and free what you can"
>> without needing to actually run the system out of pages.
> Well, the process killing only happens when we are really out of
> pages, so no amount of "free what you can" helps (unless I'm
> confused).
This was an attempt to address not the symptom but the underlying
desire. In this case, the original poster was saying, approximately,
"I wanted to do $THING and tried to do so [...outline...], and am
having $PROBLEM". Most of this thread has been talking about
addressing $PROBLEM. The above quote of mine ("Perhaps even
better...") was about addressing the desire for $THING differently, in
a way that doesn't risk provoking $PROBLEM.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
