>> What might be interesting is a way to influence the order in which
>> processes are chosen to kill...
> I don't see any realistic way of doing anything with that. It's
> basically the first process that tries to allocate another page when
> there are no more. There are no other processes at that moment in
> time that have the problem, so why should any of them be considered?
To answer that, consider the original poster's situation:
> 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. SunOS chill(1) - or was it chill(8)? -
might be another example, though that's of minimal relevance to NetBSD.
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.
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.
/~\ 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
