Re: [MiNT] XaAES / GEM memory issues

[Johan Klockars <rand@cd.chalmers.se>]

> > > Yes, I agree. I can't see why Sven sees context switches as such a
> > > problem. The only problematic thing is that the MiNT's scheduling timer

Why not?
Context switches take a lot of time.

> > > granularity is quite low (max 25 context switches per second, correct me
> > > if I am wrong). So perhaps, before anything else, we should increase the
> > > granularity to at least 50 context switches per second, and just then
> > > start to complain that IPC is slow... :-)

I can't believe MiNT only does context switches 25 times per second in
the case of synchronization/IPC/IO. That would be terrible!

When a process does something like
  send this data to process X
  wait for reply from process X
there should definitely not be a delay until the end of the time slice
until the next process gets hold of the processor.

In normal operation, most processes would be waiting on some kind of
event (input, fselect, semaphores, etc), so the receiving process X above
would probably start running immediately after the 'wait'. The work it
does would often complete before its timeslice runs out and it would
send its reply. Similar to the case above, that would make it possible
for the other process to resume execution again immediately.

If MiNT really only allows 'ping-ponging' like the above 25 times per
second, the kernel should be rewritten ASAP!
As I mentioned above, I don't believe that is the case, though.

> > In this case something must be done to improve the performance of the
> > scheduler. Lots of context switches is of little use if the CPU doesn't have
> > any time left to do real work.

It's not higher frequency preemption we need.
Context switches are not only caused by preemption in most OSes.

Fast context switches are always nice to have, but avoiding them (when that
is possible) is of course even better.

> I didn't think about setting the timer to an arbitrary value of 50
> switches per second, but keep it configurable. Thus faster machine could
> cope with higher timer granularity.

I don't think there's anything that most people do that would benefit
from 50 Hz preemption.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johank@omicron.se
                        | so hard to do |  WWW:      rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)