Ask stupid questions and you'll get a stupid answers, was: Technological advantages over Linux

[Polytropon]

On Sun, 26 Jul 2020 21:39:15 +0100, Steve O'Hara-Smith wrote:
> On Sun, 26 Jul 2020 10:56:16 -0500
> Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote:
> 
> > 
> > 
> > On 7/26/20 10:52 AM, Steve O'Hara-Smith wrote:
> > > On Sun, 26 Jul 2020 10:39:16 -0500
> > > Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote:
> > > 
> > >> My understanding of Linux OOM killer lies along same lines though my
> > >> understanding is much more simplified: kill minimal number of processes
> > >> to recover maximum amount of resources.
> > > 
> > > 	Not always the right thing to do though.
> > > 
> > >> Another speculative way to say
> > >> it would be: process owning maximum amount of RAM that keeps allocating
> > >> more RAM is first candidate.
> > > 
> > > 	What a pity if that is the heavy weight analytic program that
> > > has a run time of several hours/days and is the only thing that matters
> > > running on the system.
> > > 
> > 
> > And yes, I agreed with your sentiments (or judgement): killing a process 
> > is a bad thing always. Agreed before writing any of my comments.
> 
> 	The trouble is there really isn't anything else the OS can do
> because nobody ever thought to implement SIG_RELEASE_SOME_MEMORY_PLEASE
> which would probably be the ideal solution provided at least *some*
> programs responded to it.

As you mentioned, it depends on the problem programs ("apps") to
actually receive and act upon such a signal. "We don't need to
care for SIGMEM, because if _we_ need memore, we _need_ it, and
the fscking OS should pay attention to us and give us all that
memory!" ;-)



> 	Which leaves the only variable how to choose which process to kill
> and there are no general rules for a good choice.

The OS cannot guess what programs the user is interested in
keeping at a certain time, and what programs it could stop to
free resources, neither can it predict how programs will react
when some processes are killed from within a call hierarchy.
"If a subtask is killed, re-instantiate the task, but allocate
twice the memory it had before!" ;-)



So we're currently living with what is technically possible,
not with what we desire to happen...



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...