If you had the chance to build a new Amiga

[Gorf]

Originally Posted by meynaf

Sorry, no english videos for me - i just can't take it.
But even if you have memory protection, you still have a very nice security hole if every task is allowed to access other tasks memory space - even if it's just for reading.

it is not allowed, because we have memory protection

Well, ok, perhaps it's not a great idea to duplicate what already exists...

Fuchsia is very interesting and probably the best "traditional" kernel design out there - and it has Google supporting it...
(actually two main developers have also worked on BeOS and Nukernel-Haiku)
So if you want to go the classical route that is probably the way to go.

If you want to go microkernel and security and separated address spaces "L4" and https://genode.org/indexGenode ist the way.

If you want to go exokernel and single address space: my OS.

But does message passing really need to be THAT fast ?

It was the reason why Linux won over Minix and Hurd, and BSD over Mach.
And my OS would send even more messages than a typical microkernel OS..

If it is not at least equally fast than a monolithic kernel, it makes probably no sense - even if todays hardware is much more forgiving.

My ideas should lead to many simplifications all over the OS and make it smaller and more elegant ... sure one could argue that this would be worth some sacrifices is speed ... but historically this was never true.

but with the right support for the CPU and within a (protected!) single address space, I am confident, my approach is at least as fast an a monolithic one, probably even faster, because less complex.

Concrete example please ?

the video you don't like...

If you choose full 32 bits you escape the problems and you're limited to 4Gb memory.
If you choose full 64 bits you inherit bloat in various ways.
What's your choice ?

in that case probably 32bit ...

but maybe someone has a clever idea ... could we support different address-length in the instruction set ... like you support bytes, word, long ... for data?

actually in many cases of small programs or services even a 16bit address space would be enough.
Is there an elegant way to support different lengths dynamically?

That's right, although i don't think 'people' will support more platforms for me even if they like my vm...

worked for Linux ...

For two reasons :
1. Ease to code. Stack based horrors are out of the league.
2. Code density. Same.

and in the end dead slow ...
here a blog about some x86 emulator in wasm ... not my kind of fun:
https://brionv.com/log/2017/06/06/br...n-webassembly/

[Gorf]

An other video some might not like....
But this one is really funny and covers a lot of the ideas in this thread:

https://www.destroyallsoftware.com/t...-of-javascript

[meynaf]

Originally Posted by Gorf

it is not allowed, because we have memory protection

How can you possibly send a message to another process, if the target can't read from the pointers you give it ?
You *have* to tell the OS that these areas must be available to the other process. And then said OS has all the required information to remap them into the target's process space.

Originally Posted by Gorf

Fuchsia is very interesting and probably the best "traditional" kernel design out there - and it has Google supporting it...
(actually two main developers have also worked on BeOS and Nukernel-Haiku)
So if you want to go the classical route that is probably the way to go.

If you want to go microkernel and security and separated address spaces "L4" and https://genode.org/indexGenode ist the way.

If you want to go exokernel and single address space: my OS.

None of them satisfies me. But i, too, have a "my OS" alternative.

Originally Posted by Gorf

It was the reason why Linux won over Minix and Hurd, and BSD over Mach.
And my OS would send even more messages than a typical microkernel OS..

If it is not at least equally fast than a monolithic kernel, it makes probably no sense - even if todays hardware is much more forgiving.

My ideas should lead to many simplifications all over the OS and make it smaller and more elegant ... sure one could argue that this would be worth some sacrifices is speed ... but historically this was never true.

but with the right support for the CPU and within a (protected!) single address space, I am confident, my approach is at least as fast an a monolithic one, probably even faster, because less complex.

As you said, todays hardware is much more forgiving.
We may wonder why in spite of this, Windows is so bloat, Linux is less bloat but still is, and actually, nearly everything is.
Hint : the kernel isn't at fault. Actually, NT kernel is in fact quite good.

Originally Posted by Gorf

the video you don't like...

It's not the video i don't like, it's just that i can't the heck understand spoken english.
And anyway, if you constantly redirect to videos, it's maybe because you can't explain it yourself.

Originally Posted by Gorf

in that case probably 32bit ...

but maybe someone has a clever idea ... could we support different address-length in the instruction set ... like you support bytes, word, long ... for data?

actually in many cases of small programs or services even a 16bit address space would be enough.
Is there an elegant way to support different lengths dynamically?

It all depends how much "pushed" you want that support.
Our fine 68k can already use direct 16-bit addresses with its addressing modes ; we also have things such as MOVEA.W. I don't think it is a big deal JSR/RTS will always push/pop a long.
So i think that for 16-bit we're already covered (at least I am).

Originally Posted by Gorf

worked for Linux ...

That's because only relatively minor changes are required to get it ported to another platform. It didn't have to be 100% rewriten (not even 50%).

Originally Posted by Gorf

and in the end dead slow ...

That goes without saying.

Originally Posted by Gorf

here a blog about some x86 emulator in wasm ... not my kind of fun:
https://brionv.com/log/2017/06/06/br...n-webassembly/

This looks like brain torture...

[Gorf]

Originally Posted by meynaf

How can you possibly send a message to another process, if the target can't read from the pointers you give it ?

that is why we need to hand over full 64bit pointers on such a machine.
if the receiver has the rights to do so (MPU), it will read from (or write to) the given location

You *have* to tell the OS that these areas must be available to the other process.

you do that upfront - most of the times at the time when you allocate that region of memory.
you do NOT do that every time you send a message.

And then said OS has all the required information to remap them into the target's process space.

no - there is just one single address space all tasks live in.
The MPU blocks reads, if the task is not allowed to read, blokes writes, if the task is not allowed to write, and stopes jumps if that region is not for execution.

This is a much more static approach than remapping memory via MMU. It needs far less modifications and allows for faster context switches.

None of them satisfies me. But i, too, have a "my OS" alternative.

not even my "myOS"?

As you said, todays hardware is much more forgiving.
We may wonder why in spite of this, Windows is so bloat, Linux is less bloat but still is, and actually, nearly everything is.
Hint : the kernel isn't at fault. Actually, NT kernel is in fact quite good.

and so its the linux kernel...
but still MS considers the performance penalty of this MMU based process isolation and memory mapping etc. to 25-33%.

It's not the video i don't like, it's just that i can't the heck understand spoken english.
And anyway, if you constantly redirect to videos, it's maybe because you can't explain it yourself.

true: I can't bring down a 90 minutes lesson with lots of slides that illustrate what's going on to a few words here in the forum.
here are the slides of that talk:
http://millcomputing.com/blog/wp-con...curity.04.pptx

at least have a look at them - and ask me for the parts that are unclear and I will explain these parts instead of writing a whole book here...

It all depends how much "pushed" you want that support.
Our fine 68k can already use direct 16-bit addresses with its addressing modes ; we also have things such as MOVEA.W. I don't think it is a big deal JSR/RTS will always push/pop a long.
So i think that for 16-bit we're already covered (at least I am).

so let's do the same for 32bit in a 64bit CPU.
that should avoid the drawbacks of long pointers, as you would not use them most of the time, but 32bit or even 16bit instead.

[meynaf]

Originally Posted by Gorf

that is why we need to hand over full 64bit pointers on such a machine.
if the receiver has the rights to do so (MPU), it will read from (or write to) the given location

So the MMU (call it MPU if you want) needs to define these areas, even if it's just for access flags. But little has to be added to also change the physical area they map to...

Originally Posted by Gorf

you do that upfront - most of the times at the time when you allocate that region of memory.
you do NOT do that every time you send a message.

I conclude from this that you allocate this memory with special flags, in a similar way we ask for chipmem on the miggy. Am i right ?

Originally Posted by Gorf

no - there is just one single address space all tasks live in.
The MPU blocks reads, if the task is not allowed to read, blokes writes, if the task is not allowed to write, and stopes jumps if that region is not for execution.

This is a much more static approach than remapping memory via MMU. It needs far less modifications and allows for faster context switches.

Yes but the OS could remap the areas of the tasks without any problem. It's just that you don't want to do it for performance purpose.

Originally Posted by Gorf

not even my "myOS"?

Nope
But let's face it : i have nothing against you writing your OS for my CPU if you want to.

Originally Posted by Gorf

and so its the linux kernel...
but still MS considers the performance penalty of this MMU based process isolation and memory mapping etc. to 25-33%.

So this is a MS guy dreaming about his own system back in 2006 (read the publication date). Totally uninteresting to me. Every OS writer wannabe can write their own benchmarks that would kill existing OSes.

Originally Posted by Gorf

true: I can't bring down a 90 minutes lesson with lots of slides that illustrate what's going on to a few words here in the forum.
here are the slides of that talk:
http://millcomputing.com/blog/wp-con...curity.04.pptx

at least have a look at them - and ask me for the parts that are unclear and I will explain these parts instead of writing a whole book here...

Wow, 90 minutes lesson and whole book. I thought you wanted it to be simple.

It seems you want to both keep your cake and eat it
My plan to handle this is to give the choice. Same OS could work with full security, or limited, or even no memory protection at all (like AOS 3.x).

Oh, while i'm at it. What's described here is very implementation oriented. It needs special hardware. In short, it does not mix well with a software VM...

Originally Posted by Gorf

so let's do the same for 32bit in a 64bit CPU.
that should avoid the drawbacks of long pointers, as you would not use them most of the time, but 32bit or even 16bit instead.

Removing single bucket of water will not empty the pond. 64bit has more important drawbacks than just the pointer overhead.

[Gorf]

Originally Posted by meynaf

So the MMU (call it MPU if you want) needs to define these areas, even if it's just for access flags. But little has to be added to also change the physical area they map to...

except that mapping is different for every process and has to change at every context switch in the classical approach, while the MPU approach does allow to keep the same tables and only make changes if new permissions are granted ..

I conclude from this that you allocate this memory with special flags, in a similar way we ask for chipmem on the miggy. Am i right ?

Right. But these can be much more fine grained.
Think of "groups" like permissions on a filesystem.

Yes but the OS could remap the areas of the tasks without any problem. It's just that you don't want to do it for performance purpose.

performance, simplicity and elegance.

Nope
But let's face it : i have nothing against you writing your OS for my CPU if you want to.

so I have to implement my own CPU, so that you can port your OS over to it?

So this is a MS guy dreaming about his own system back in 2006 (read the publication date). Totally uninteresting to me. Every OS writer wannabe can write their own benchmarks that would kill existing OSes.

Project "Singularity" wasn't just "some guy" at Microsoft but a whole research team over the period of seven years..

Wow, 90 minutes lesson and whole book. I thought you wanted it to be simple.

still shorter and simpler if you compare it to same lesson on how CPU, MMU, kernel, tasks on todays systems. It is just, that we know these things already or have at least an idea about how it works.
If you would explain it from the scratch it takes also a very long time.

the MPU/security concept in this linked talk, rethinks the whole concept ...

It seems you want to both keep your cake and eat it

What is a cake good for, if you can't eat it?

My plan to handle this is to give the choice. Same OS could work with full security, or limited, or even no memory protection at all (like AOS 3.x).

that would also be possible in my approach. You can grant as many or as few permissions as you see fit.
A system should not take the (power)users control away...

Oh, while i'm at it. What's described here is very implementation oriented. It needs special hardware. In short, it does not mix well with a software VM...

I don't see why not. Actually the opposite: as long as there is no real hardware supporting this, software VM is the only way to implement it.

Since for the host CPU the VM looks like any other program running in its own address space, it is entirely up to the VM how it implements process isolation..

Removing single bucket of water will not empty the pond. 64bit has more important drawbacks than just the pointer overhead.

such as?

[meynaf]

Originally Posted by Gorf

except that mapping is different for every process and has to change at every context switch in the classical approach, while the MPU approach does allow to keep the same tables and only make changes if new permissions are granted ..

Have you thought about the size of said tables ?
One mapping per process, kept permanently. Ouch.

Originally Posted by Gorf

Right. But these can be much more fine grained.
Think of "groups" like permissions on a filesystem.

But the trick is, that when doing such an mem allocation nothing prevents passing some kind of "32BitMem" flag as well...

Originally Posted by Gorf

performance, simplicity and elegance.

And big trouble handling 32 vs 64 bits

Originally Posted by Gorf

so I have to implement my own CPU, so that you can port your OS over to it?

Port my OS, no. But perform some code density comparisons so i can kick your butts, yes

Originally Posted by Gorf

Project "Singularity" wasn't just "some guy" at Microsoft but a whole research team over the period of seven years..

... Which ended up nowhere.
https://en.wikipedia.org/wiki/Singul...rating_system)
Working state : Discontinued. Oops.

Originally Posted by Gorf

still shorter and simpler if you compare it to same lesson on how CPU, MMU, kernel, tasks on todays systems. It is just, that we know these things already or have at least an idea about how it works.
If you would explain it from the scratch it takes also a very long time.

the MPU/security concept in this linked talk, rethinks the whole concept ...

Perhaps they should rethink that whole concept again, as it still looks too complicated for what it does.

Originally Posted by Gorf

What is a cake good for, if you can't eat it?

Well, said otherwise, you want both the butter and the money for the butter.

Originally Posted by Gorf

that would also be possible in my approach. You can grant as many or as few permissions as you see fit.
A system should not take the (power)users control away...

That's not the same. Granting permissions isn't the same thing as completely shutting them off (which is, and always will be, faster and simpler).

Originally Posted by Gorf

I don't see why not. Actually the opposite: as long as there is no real hardware supporting this, software VM is the only way to implement it.

Since for the host CPU the VM looks like any other program running in its own address space, it is entirely up to the VM how it implements process isolation..

Do you realise how costly it is to run a MPU by pure software ?

Originally Posted by Gorf

such as?

Try to design it and you will see.

[Gorf]

Originally Posted by meynaf

Have you thought about the size of said tables ?
One mapping per process, kept permanently. Ouch.

much smaller than the way it is handled now in most operating systems.

But the trick is, that when doing such an mem allocation nothing prevents passing some kind of "32BitMem" flag as well...

the memory (or MPU) should not care how the the CPU is going to interpret the data on it.
Only it it is is allowed to access it.

And big trouble handling 32 vs 64 bits

it has no problem at all.
the only problem we are talking here arises from insisting on a hybrid CPU-design.
If our address space is 64bit, the CPU has to cope with it and provide a mechanism to handle 64bit pointers for IPC.
It may also use shorter pointers for references within the own heap.

Port my OS, no. But perform some code density comparisons so i can kick your butts, yes

looking forward to it

... Which ended up nowhere.
https://en.wikipedia.org/wiki/Singul...rating_system)
Working state : Discontinued. Oops.

but that does not invalidate the research, that was done in the process.

Perhaps they should rethink that whole concept again, as it still looks too complicated for what it does.

for me it looks much simpler than the current way of doing things.
(and one could strip it further down, as probably not all features mentioned in that talk are necessary)

Well, said otherwise, you want both the butter and the money for the butter.

no: I want the cow.

That's not the same. Granting permissions isn't the same thing as completely shutting them off (which is, and always will be, faster and simpler).

there is no difference here, since you are also going to provide more security if the user wishes it. So the complexity is there, no matter if you use that feature or not.
In my approach the complexity also stays constant, and the speed penalty is close to zero, as the checks are done in parallel.

Do you realise how costly it is to run a MPU by pure software ?

as it is NOT a MMU: not that high.
Here again some of the techniques used in Singularity (and probably in many other places as well) can help to provide such a MPU-like system in a VM. It does not need to replicate a hardware MPU but just deliver the same effects..

Try to design it and you will see.

that is not an answer

What are the other important drawbacks a 64bit CPU imposes besides the pointer overhead?

[meynaf]

Originally Posted by Gorf

much smaller than the way it is handled now in most operating systems.

But this one single table for everyone is still much bigger than a single process table. So at a given time, there is more info to handle, not less. Unless your "keep the same tables" was wrong ?
Sorry, but you can not have a table for n tasks smaller than a table for 1 task. If there are many tasks in the system, your table will explode - unless you have 1 table for 1 task and in that case, you're doing the same as everyone else (i.e. invalidating the table upon task switches).

Originally Posted by Gorf

the memory (or MPU) should not care how the the CPU is going to interpret the data on it.
Only it it is is allowed to access it.

The flag is for the memory allocator of the OS, not for the MPU.

Originally Posted by Gorf

it has no problem at all.
the only problem we are talking here arises from insisting on a hybrid CPU-design.
If our address space is 64bit, the CPU has to cope with it and provide a mechanism to handle 64bit pointers for IPC.
It may also use shorter pointers for references within the own heap.

Is it me insisting on using a hybrid system, or you insisting on using a memory protection scheme that will not work ?

Originally Posted by Gorf

looking forward to it

When you want. I'm ready

Originally Posted by Gorf

but that does not invalidate the research, that was done in the process.

And aside of a defunct (and never really used) OS and nice theories on the paper, what has come out of it ?

Originally Posted by Gorf

for me it looks much simpler than the current way of doing things.
(and one could strip it further down, as probably not all features mentioned in that talk are necessary)

Of course but the current way isn't exactly a good reference...

Originally Posted by Gorf

no: I want the cow.

You can't have it.
You have the choice between security and performance. You can't have both together at a given time.

Originally Posted by Gorf

there is no difference here, since you are also going to provide more security if the user wishes it. So the complexity is there, no matter if you use that feature or not.

That's just a currently unused module. It doesn't really add complexity. (I will not go for a monolithic thing, heh !)

Originally Posted by Gorf

In my approach the complexity also stays constant, and the speed penalty is close to zero, as the checks are done in parallel.

In a normal TLB the checks are done in parallel too, aren't they ?
Now can you check the whole mem lists of 100+ tasks in parallel ?

Originally Posted by Gorf

as it is NOT a MMU: not that high.
Here again some of the techniques used in Singularity (and probably in many other places as well) can help to provide such a MPU-like system in a VM. It does not need to replicate a hardware MPU but just deliver the same effects..

It needs to control all accesses, so still very high.

Originally Posted by Gorf

that is not an answer

What are the other important drawbacks a 64bit CPU imposes besides the pointer overhead?

This is quite empiric knowledge, and an attempt to design a full instruction set and its encoding, with 64 bit support, would be a lot better than me attempting to explain it (i did try to do it).

But hey, let's have a go, hoping it will not result in endless arguing.

Do you want to reduce the feature level of your cpu, or use an ugly encoding ? As with up to 25% space used for 64-bit features, you'll be forced to do major changes.
Have you considered what would be the maximum size of a single instruction ? This becomes interesting if you can have full sized immediates and linear addresses in your addressing modes.
Ah, and don't forget to allocate more space in structures, stacks, whatever, as your registers are now twice as big (and more space in your MPU lists, as your address space is now squared).

[Gorf]

Originally Posted by meynaf

But this one single table for everyone is still much bigger than a single process table.
...
In a normal TLB the checks are done in parallel too, aren't they ?
Now can you check the whole mem lists of 100+ tasks in parallel ?
....

Of course you don't check hundreds (or more) of "mem lists" - that would be utterly stupid. How do you come up with such an idea?

ok ... you don't want to watch the video and you don't want to read the slides i linked ...
but still you keep making totally wrong assumptions.

To me it seems you don't really want to talk about it in a productive way.
So we better stopp here.

[meynaf]

Originally Posted by Gorf

Of course you don't check hundreds (or more) of "mem lists" - that would be utterly stupid. How do you come up with such an idea?

Because you indirectly suggested it ?
Who wrote "the MPU approach does allow to keep the same tables" ?
It strongly suggests the table is the same for the whole system. Otherwise, it contradicts the previous "mapping is different for every process and has to change at every context switch in the classical approach" which suggests that you don't go to another table upon context switch.
Either the mapping changes, or it does not.
(Of course, in the Mill stuff you linked, the table actually changes, it's just able to reuse blocks of others - which does not look like if it'll have a positive impact on speed, and certainly not on simplicity.)

Originally Posted by Gorf

ok ... you don't want to watch the video and you don't want to read the slides i linked ...

Wrong assumption. I really did read the slide, from start to end. But did you really understand what it all means ? If you master something, you can explain it, or at least give a simple example.

Originally Posted by Gorf

but still you keep making totally wrong assumptions.

And of course you're not saying what assuptions might be wrong and why. I take notice of that.

However is it me, or you ? I just wanted to push you to make your thought clear, point your contradictions, sometimes reasoning by the absurd.

But here is one fact : my VM actually works. It runs on 68k only, it's slow, it's not available to the public, but it works. Yours looks like it's just a vague theory.

Originally Posted by Gorf

To me it seems you don't really want to talk about it in a productive way.
So we better stopp here.

Oh no, here we go again. Simply not agreeing intepreted as not wanting to talk. IOW, "productive way" = "you must agree with me".
How odd people just stop talking when they are proven wrong.

Now you wanna stop ? That's fine. Build a working VM, then we'll talk again.

[Gorf]

It is not about agreeing or disagreeing, but about twisting words or saying things like just now: "you indirectly suggested it"
No I did nowhere suggest to search hundreds of "memory lists" per task and it is kind of insulting to claim I would suggest such nonsense.

A tables containing less information must be smaller than ones containing more information!
Since you do not need to store the physical address in a SASOS MPU table, less memory is needed in total compared to classical MMU tables.
For a 64Bit CPU the entry can shrink down from 64 bits (like on x64) to 32 bits per entry and still providing a more sophisticated permission model.

Of course they are not static (and I never claimed that either) but they only need to change if memory gets allocated, freed or permissions get granted and not every context switch, since all tasks live in the same "memory context" aka the same address space.

Or now claiming you had "proven me wrong" ... there was nothing to be proven wrong or right, except you make up nonsensical things I never claimed in the first place.

THAT ist what I call a non-productive way to discuss a matter.

So sorry @all for the derailing and back to the topic: your dream amiga

[meynaf]

Originally Posted by Gorf

It is not about agreeing or disagreeing, but about twisting words or saying things like just now: "you indirectly suggested it"

I am not twisting words, this was really what you suggested -- even if unintentionally.

Originally Posted by Gorf

No I did nowhere suggest to search hundreds of "memory lists" per task and it is kind of insulting to claim I would suggest such nonsense.

You really wrote "the MPU approach does allow to keep the same tables".
What conclusion to take from this ?
If we switch to another table, then we don't keep the same table - doing exactly like the others.
And if we don't switch anything at all, then there must be a single, global table.
This global table must then handle hundreds of lists because there are hundreds of tasks (and not hundreds of lists per task !).
Yes this is absurd. But it is the logical conclusion.

Originally Posted by Gorf

A tables containing less information must be smaller than ones containing more information!

But 100 tables containing less information aren't together smaller than a single one containing more information.

Originally Posted by Gorf

Since you do not need to store the physical address in a SASOS MPU table, less memory is needed in total compared to classical MMU tables.

But classical MMU tables are for single task. And the point isn't really about used memory, but about used cache for entry lookouts.

Anyway, does your MPU table use variable sized blocks ? In that case, ok you don't have the physical address, but you have the size.

Originally Posted by Gorf

For a 64Bit CPU the entry can shrink down from 64 bits (like on x64) to 32 bits per entry and still providing a more sophisticated permission model.

The main problem for 64bit isn't the size of individual entries, it's nothing in comparison to the overall number of entries.
Oh, wait. Maybe entries describe areas that vary in size ? In that case, either they're small enough and lead to horrors in case of fragmentation, or they're big and they lead to memory waste exactly like in the classical way (but not in my "no protection at all" idea).

Originally Posted by Gorf

Of course they are not static (and I never claimed that either) but they only need to change if memory gets allocated, freed or permissions get granted and not every context switch, since all tasks live in the same "memory context" aka the same address space.

But classical tables don't need to change more than that. You just switch to another one and at the end it's exactly the same.
Don't tell me you think the tables are fully rebuilt upon every context switch for the classical way ?!

Furthermore, in the classical way as done nowadays we're multicore. This means, greatly reduced number of context switches so they don't count that much anymore in performance.

Originally Posted by Gorf

Or now claiming you had "proven me wrong" ... there was nothing to be proven wrong or right, except you make up nonsensical things I never claimed in the first place.

Your overreaction is a proof by itself.
Check post #91 : no reply to all my points, and count the number of "you" in it...
For me a clear indication i have touched something sensitive.

Originally Posted by Gorf

THAT ist what I call a non-productive way to discuss a matter.

'xcept you are not really discussing. You're just sending me to videos or whatever. If you need someone else to explain things in your place, it's because you can't explain it yourself. And if you can't explain it yourself, it's probably because you haven't really understood it.
You don't need me to do it, do you ? So why are you not just working on it ? We've got enough time these days !

Originally Posted by Gorf

So sorry @all for the derailing and back to the topic: your dream amiga

Yeah, sure.

[Gorf]

Originally Posted by meynaf

I am not twisting words, this was really what you suggested -- even if unintentionally.

You really wrote "the MPU approach does allow to keep the same tables".
What conclusion to take from this ?

That you do not have to change it during a context switch.

If we switch to another table, then we don't keep the same table - doing exactly like the others.
And if we don't switch anything at all, then there must be a single, global table.

Yes - one table

This global table must then handle hundreds of lists

NO!

because there are hundreds of tasks (and not hundreds of lists per task !).
Yes this is absurd. But it is the logical conclusion.

No the conclusion is absurd.
You need just one list.

On a file server with hundreds of users and millions of files, you do not need hundreds of lists with millions of entries to organize permissions.
You only have a few per file, that your filesystem manages.
Same goes here for tasks and memory regions.

But 100 tables containing less information aren't together smaller than a single one containing more information.

Luckily we need just one

But classical MMU tables are for single task. And the point isn't really about used memory, but about used cache for entry lookouts.

And now we can keep everything at least in the 2nd level cache of our MPU (2-4 million lines) and we can share this cache with many cores.

Anyway, does your MPU table use variable sized blocks ? In that case, ok you don't have the physical address, but you have the size.

Above line count was for fixed size - if you use a variable size you can reduce the number of lines but you complicate the handling...

The main problem for 64bit isn't the size of individual entries, it's nothing in comparison to the overall number of entries.

Since you do not actually use the full 64Bit address space and probably never will in our lifetime the number of actual entries gets drastically reduced.

About 4M lines for 64GB of ram and 16KB regions.

If you want a more fine grained structure, you can accompany this with tagged memory, down to the byte level.
(See lowRISC cpu)

Oh, wait. Maybe entries describe areas that vary in size ? In that case, either they're small enough and lead to horrors in case of fragmentation, or they're big and they lead to memory waste exactly like in the classical way (but not in my "no protection at all" idea).

See above.

But classical tables don't need to change more than that. You just switch to another one and at the end it's exactly the same.

They don’t need to change if you change them?
That makes no sense...

Don't tell me you think the tables are fully rebuilt upon every context switch for the classical way ?!

Of course not, but the switch is costly enough, since you Have to flush you buffers ...
See the paper from Microsoft I linked earlier..

Furthermore, in the classical way as done nowadays we're multicore. This means, greatly reduced number of context switches so they don't count that much anymore in performance.

Only as long as your tasks don’t want to exchange any information...
And since tasks now spawn multiple thread ... well I somehow doubt, that the number of switches got actually significantly reduced.
Are there studies?

'xcept you are not really discussing. You're just sending me to videos or whatever.

How dare I to post actual information...

If you need someone else to explain things in your place, it's because you can't explain it yourself.

Or because it takes to long, or there are a lot of pictures, or a video, or just some very good explanation by an expert ....

Did you never read books in school/university, but demanded, that your teachers explains everything for you?
How did they react?

And if you can't explain it yourself, it's probably because you haven't really understood it.

And if your teachers told you to read a chapter until tomorrow for a test, you would think, they don’t know what’s in the book?

You don't need me to do it, do you ?

Probably not more than you need me

So why are you not just working on it ? We've got enough time these days !

Again making assumptions
I actually don’t...

[spiff]

Gorf, do you use Vim or Emacs?

[Gorf]

Originally Posted by spiff

Gorf, do you use Vim or Emacs?

If there is just a terminal Vim.
But actually I do prefer more comfortable editors like Sublime.
Why? (Is that a trick question?)

[Samurai_Crow]

If Gorf's idea is to make a variable-sized table of resources without need for relationships then it's going to be faster than a relational SQL database and smaller than a linked structure. The real question is this: How are reallocations handled in the global table?

[Gorf]

You can make the table fixed size, since your actual physical RAM is not going to change ... but it will contain many identical entries, so there is room for compression ... If you have a fast enough way to access the data in a compressed table ...

The easy way: just a fixed size table with a known number of entries.
The MemAllocator service will simply overwrite the table at specific location in case of a reallocation. That location can simply be calculated.

[Samurai_Crow]

@Gorf
What will the page size be for the MPU?

[Gorf]

Originally Posted by Samurai_Crow

@Gorf
What will the page size be for the MPU?

I called it "regions" in the last message ... and there I took 16KB as region-size for a computer with 64GB installed...

(This is obviously for a 64bit cpu)

If you have less RAM you can make the regions smaller or work with a smaller table ... I would recommend the second option