tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: killed: out of swap





On 2022-06-14 20:47, Mouse wrote:
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.

Well. First of all, such a program don't exist, as the malloc is not failing.

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? Are you sure it is a better candidate than the current process, who actually are demanding more pages at the moment? The other process might not in fact ever be hitting the condition, and would run on happily ever after, even though it did call malloc a number of times earlier.

Even more, how do we decide that it's actually malloc, or are any memory demand treated equally?

And yes, it also raises the question on how to handle the current process that caused a page demand that cannot be fulfilled at the moment.

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).

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


Home | Main Index | Thread Index | Old Index