tech-kern archive

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

Re: killed: out of swap



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

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

> Is this something madvise(2) could be extended to do?

In principle?  It could be, sure.

I would, however, suggest something else.  These operations do not
apply to specific ranges of VM, so an API that's designed for actions
on particular ranges of VM seems inappropriate.

For the former suggestion, for declaring a process a preferred (or
maybe even dispreferred) out-of-swap victim, sysctl's proc.$PID....
hierarchy strikes me as a better tool, especially because root can then
protect certain processes from the command line, by making them less
preferred.

I didn't go into details of what I was imagining.  I was thinking of
each process having a preference; when the kernel runs out of swap,
instead of simply killing the faulting process it would kill one of the
processes with the maximum victim preference value, perhaps a signed
int with the default being zero or some such.  Then root could set
preference negative for particularly important processes, or positive
for fluff, or very positive for things like the "try to reclaim RAM"
process outlined.  I would say it should be like nice: any process can
make itself get less-preferred treatment, but it should take privilege
to go the other way.

For the latter suggestion, for provoking what reclaims are possible
without actually risking running out of pages...I'm not sure.  A new
syscall?  A new sysctl?  An ioctl on /dev/mem?  There are many
possibilities.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index