RPI3 swap experiments (grace under pressure)

[bob prohaska]

On Tue, Aug 14, 2018 at 05:56:20PM +1000, Patrick Crilly wrote:
> On 14-Aug-18 11:42 AM, bob prohaska wrote:
> > I understand that the RPi isn't a primary platform for FreeBSD.
> > But, decent performance under overload seems like a universal
> > problem that's always worth solving, whether for a computer or
> > an office. The exact goals might vary, but coping with too much
> > to do and not enough to do it with is humanity's oldest puzzle.
> 
> It's a very difficult problem to solve.?? And provokes some pretty heated 
> arguments.

Understood. The arguments that apply to a Mars rover don't apply to a
rack server, and vice versa. To a degree I'm hoping for Mars rover behavior 
by a rack server OS on a smartphone platform 8-)
> 
> If you are experiencing overload, then there's a case for saying the 
> platform/system isup to the task.
                  ^^^^
Did you mean to say "isn't up"? In general, I agree in that case.

> >   
> > Maybe I should ask what the goals of the OOMA process serve.
> > I always thought an OS's goals were along the lines of:
> > 1. maintain control
> > 2. get the work done
> > 3. remain responsive
> >
> > OOMA seems to sacrifice getting work done, potentially entirely,
> > in support of keeping the system responsive and under control.
> 
Yes, but it seems to be the _first_visible_  response. Seems to me it would
be better reserved as a last resort.

> I believe the thinking is that if the system remains remains responsive 
> you have a chance of fixing the problem or at the very least you can 
> login and gather information about what is causing the problem.
>
Yes, some responsiveness is needed to distinguish from stuck.  
> >
> > To have some fun with the office analogy, when business is
> > slow the clerk serves customers as they come in. When things
> > get busy, the clerk says "take a number". When they get really
> > busy new customers are told "come back tomorrow" and when they
> > get absolutely frantic present customers are told "I can't finish
> > this now, I'll call you when it's done". That's grace under pressure.
> 
> Nice analogy. If people just keep coming all day, I think what you've 
> described is a responsive system.
 
I'm thinking of transient overloads; for permanent overloads there's no hope.
"Transient" would be more than a task duration but less than a vacation interval,
by how much I'm not sure, but it would scale with those intervals.

> The clerk isn't getting any work done,?? he's just responding to customers.?? 

The clerk is timesharing, going from one task to the next in turn. Response time
will suffer, because that's the only elasticity left in the problem. 
 
> And would "can't finish it now" be analogous to killing?? off processes?
Not if the "I'll call you when it's done" is honored. The task is placed in
a queue, finished when the overload passes, and the clerk returns the results.
When the queue gets short enough he begins starting new tasks again. Mark M.
equated this with swapping, as opposed to paging and I think he's right. 

In a sense, the "I'll call you when it's done" is like an old-fashioned 
batch processing scheme. Does FreeBSD have any vestigal remnant features
for accepting batch jobs? High nicenes is similar but still interactive. 
 
Responsiveness, if only to say "There are nnn tasks ahead of you, please call 
back after ....." is the only degree of freedom left. Exactly out how bad to 
let that get before admitting defeat would vary greatly between an interactive
job and a batch job.

To a degree, OOMA is biased toward interactive use. Buildworld  is 
more like a batch job.

Thanks for reading!

bob prohaska