Re: Supervisor mode & multitasking

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

Rather than writing a dozen separate replies, I decided to group together
what I have to say in one letter.
With all the recent traffic on the MiNT list, I've had to add and remove
things from this reply a couple of times now. I hope it's not too incoherent.

> >As I know from someone else (hi, Anders ;)), BadMood developers need
> >multitasking in supervisor to make the program networkable.  As I looked
> >at the Super() and Supexec() system calls, they can't be fixed easily to
> >do that, besides, it might broke compatibility with existing software (you
> >never know which program takes advantage of the fact that there's no
> >multitasking in supermode). So, the best solution for now is, in my
> >opinion, to add the THIRD system call referring to the supervisor mode.
> 
> So if I understand you, you're going to add a BadMood specific call into
> MiNT kernel? Why? Do you think BadMood players would ever install MiNT? And

BAD MOOD isn't the only program that could benefit from such a call.

> 1) BadMood, to run fast on Falcon, has to run in supervisor, because it
> wants to utilize as many CPU power as possible.

No, that's not why.
Under standard TOS, supervisor mode doesn't buy you anything and current
BAD MOOD isn't written to be used with MiNT.

The problem that the call would address is that some software need access
to the hardware registers often and performance would go down drastically
if Super/Supexec was needed every single time.
In BAD MOOD the DSP is accessed frequently and that needs supervisor mode.

> 2) supervisor stops multitasking.
> 3) mintnet needs multitasking
> 4) so, is it currently possible to run games like BadMood networked using
>    MiNT-Net?
> 5) answer: no, its completely impossible.
> 
> Hence the idea. But if you all think its more dangerous (because of normal
> programmers' lazyness), than advantageous, I can cancel this function.

No! Don't cancel it, _please_!

It was agreed earlier that it would be next to impossible to remove the
possibility for user programs to run in supervisor mode.
The least we can do is to make sure that the offending programs are still
scheduled!

> Besides, if BadMood steals the VBL autovector for itself and exists the
> VBL using RTE, it won't multitask anyways.

I wouldn't be surprised if there were other problems with the current
BAD MOOD under MiNT, but it doesn't have to stay that way.

> do you think BadMood will be finished?

Now, don't be so negative.  ;-)


> For the XBIOS code, the solution is quite simple: just to patch all xbios
> calls into MiNT (by the way, Yves, Falcon XBIOS functions aren't defined
> in the library!!! :( ). This is also possible for VDI, but not for the
> AES, as the AES is mainly not present in the system while MiNT gets

As has been mentioned, the VDI can be exchanged for NVDI later on. There
are also other things that intercept the TRAP vectors.


> I think that for now we may stay with such a limitation, that only one
> supervisor may be running in multitasking at a time (i.e. the rest of
> tasks has to be usermode).

What would that gain us, apart from halfway supporting the kind of mutual
exclusion that supervisor mode used to guarantee?

> Aha, I forgot. I added some sort of singlemode to the kernel. As I know
> Gryf requested that for Thing, here goes the proper call:

Since lots of people don't seem to like that, I think you need to add an
on/off switch for that in mint.cnf. That way everybody could have it the
way they like best.

Personally, I don't really see any problem with it. Going into supervisor
mode to stop multitasking is a much larger sin, IMHO, and there are some
old programs (not that I use any) that apparently hate multitasking.


> I think it is a guaranteed system feature that there is no task
> switching in supervisor mode. Why would you want to change that?

The way I recall it, this was claimed to be subject to change, but you
may well be right.
It's still a very silly rule.

Ideally, _no_ user rogram should ever be allowed into supervisor mode.
If that is allowed, there's never going to be any way to stop a task
from hanging the entire system. Memory protection doesn't help since
it's easy to disable interrupts and then enter a loop. That could happen
accidentaly as well as by design.


> > Nevertheless, this may be done, but it doesn't guarantee 100% stability. 
> > As I know from someone else (hi, Anders ;)), BadMood developers need
> > multitasking in supervisor to make the program networkable.  As I looked
>
> True, but then it also relies on the fact that other processes are not
> trying to write to the screen...

That's no problem. Every single process that tries to write to the screen
relies on noone else doing it at the same time. Whether they use the VDI or
not.

There have always been calls in the AES to get around this.


> the system. All (I meant: ALL) XBIOS functions need such restriction in
...
> However, XBIOS restriction is delayed becayse MiNTLibs doesn't define any
> Falcon XBIOS call. I'll be sitting on this next days, Yves, exspect a

Why would you need that? You said _all_ XBIOS functions should be protected,
which would be easy enough to do with a TRAP handler.


> >Yes, it may be. But sometimes it may be nice to have an option to
> >write/run a program, which takes an advantage of being the only task in
> >the system to utilize the full processing power of the CPU. As the
> 
> I don't agree. We should improve MiNT scheduling so a time intensive task

How could there ever be a reason to require the full processing power?
That's a variable quantity and it should definitely be up to the user how
he wants to use it.

> will  get 97% (or more) of CPU power. Then, you wouldn't need to switch to
> singlemode.

Uhm, if every other task is waiting for IO, I think a "time intensive"
task would get 100% (minus MiNT overhead) of the processor.
If any other tasks also aren't waiting for IO (or blocking for other reasons),
they are also "time intensive", by definition.


> So we actually need a new debugger for MiNTOS, not singlemode in MiNT. OK, I
> agree - so let's develop a new, MiNT friendly debugger. Sven started work on
> something, it could even utilize special MiNT debugging features.

Wasn't Craig Graham's Lattice C source level debugger MiNT friendly too?
I haven't got around to testing it yet...

> sorry, I am still not convinced the single mode is really neccessary. It
> might be handy, but the danger of misuse is rather high, I am afraid.

Then do as I suggested above and make it a user selectable option.

> Similarly, the system call for switching to super mode while allowing task
> switching - this might affect complete system stability. Again, with such

Why? If it can be done in a way that ensures that no double entries into
non-reentrant TRAP handlers (probably most not written by Atari), I think it
would be just fine.

> call there might appear applications which will be dangerous for whole
> operating system. Do I see the future too black?

There might of course be a few programs that use supervisor mode for
access control to variables and such, but I doubt there are many.

Those programs could be modified to use the "single task" call instead,
giving the same effect.


> It's almost the same, as 3% of the 68030 processing power won't be
> sufficient for almost anything. Anyways, I have an impression that MiNT
> scheduler can't be improved to a big extent (like twice as fast).

I agree. And even if it was twice as fast, I doubt you would notice it.

> And where is Sven? Doesn't he endup like Jerry Geiger, who, after months

A very good question.

> of dark silence finally decided to mail few persons that he left the Atari
> world?

Fortunately, I think that's very unlikely. Some parts of his WWW pages
were definitely updated in January.


> How much time is stolen by background tasks in current, fully loaded MiNTOS
> setup? I would say it's less than 10%. And with better prioritization there

I would agree.
What background tasks are there that aren't blocked waiting on IO, anyway?

> As for the 3% number - the point is to get enough time to the actual
> application automatically, without any system call for stopping
> multitasking.

Wasn't the "single task" call supposed to be for tasks that simple can't
deal with multitasking? 

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