Why does Linux need memory management units and cache?

To implement virtual address spaces for processes.

There are micro-Linux-systems that do not do that, and can run without
memory management units. But this means that a process can mess up the
private memory of another process, by mistake or maliciously.



Linux doesn't need cache, logically. But Linux systems usually need lots
of memory, more than can be provided on chip, and access to off-chip
memories is usually so slow that a cache makes the system much faster.

Virtual address space in a nut shell means program counter relative
operation. So if I were careful to keep supervisory
programs separate from user programs, and manage my address
space of user programs with PC relative addressing,
I won't need memory management hardware. All I need is a
fast program that keeps the virtual memory management functions
going because that should still be faster than setting up MMU
and managing its operations.




So a cache could be implemented in software. And if done properly
with a fast program, it should run faster and better than
hardware which would use up a lot more software
in setting up and managing a cache.

[...]


Actually, that's more or less what Amiga was doing
and many Real Time OSes.

It is faster, also faster to crash, since programs
could, -intentionally or unintentionally-, address
memory which they should not.



I doubt it is possible, unless the CPU supports such
things, having, for example, some scratch pad RAM.

Since cache is cache, i.e. fast but small memory, it
has to be an hardware component.
How this hardware is handled, is CPU dependent.

bye,

That is trivial to address.
The crashing can be prevented if PC relative
addressing had bound checking hardware that executes trap
whenever address range is out of bounds.

So MMU is not needed if Linux could manage its
memory with fast software, and if CPUs came equipped
with bound checking for PC relative addressing.

 


A cache could be more effective if smart
software precisely keeps tabs on what
the DMA controller is doing; and programs that
are running have fine grained messaging that lets
the cache know what is happening with them.
That way cache fetching could be aborted and flushed
more rapidly than letting the cache decide what
to cache. Aborting a cache operation can save tons
of time on a CPU because typically it can take
hundreds of nanoseconds to microseconds
to set up another fetch from somewhere else,
whilst during that time, 100+ instructions
could have executed making an intelligent
decision as to what best to cache.

So in my opinion, hardware based
caching is a waste of time.

So to the best of my opinion,
with these ultra modern CPUs that are running at
gigahertz speeds, the most important advancements
for an operating system and speed is better software
for software implementation of MMU and better software for caching
and to remove the hardware MMU and hardware cache
(and in its place put in more DMA controllers and local RAM).

[...]


Which means you need HW support, which means
you need a MMU, giving you the luxury to not
care of the problem in the software.



Well, if... What is available is MMU, should
someone consider to inform intel, or others,
about some possible HW improvement?

[...]


DMA controller is not enough, what is needed
is a fast memory too.

In any case, HW support is needed.
Likely it is possible to improve CPUs architecture,
but that's not a software problem.



It seems you're quite optimistic in your description,
have you real tried to to calculate the numbers?
What you depict might work under some circumstances,
namely: a "smart" DMA is available, some RAM as fast
as a cache, quite a lot of data need to be transferred.
The last condition is due to the fact that DMA takes
time too, in order to start or stop operations.



Yep, you might want to look at Cell architecture,
you'll find a lot of that.

In any case, as mentioned above, this has nothing to
do with software, it a hardware architecture issue.

bye,

I'm not so sure about that today.
It used to be that CPUs would execute some 10 to 100 MIPs
and memory was not much different and thus an MMU had
had to be used to handle data because there just isn't enough
CPU cycles to handle all the processing.

Nowadays however, CPUs are executing some 1 to 2 giga MIPS
and that is trouble if anyone thinks harware MMUs and caching
is a good idea to propagate.

RAM has stayed put at around 10 million random accesses
per second. And flash is microseconds for random access.
This has meant that
CPUs can now perform 10 to 100's of instructions in the time
it takes for RAM or flash to service a random read.
Whilst DMA takes care of burst mode operating conditions
for RAM and flash, there is gap right there when
RAM and flash is unable to send data servicing a random
data request.

That service interval may look tiny, but brings utter
disaster to desktop applications, games and anything that
wants speedy processing of data.

No, that's not what virtual address space means.



Not really, no.



Nope.

Nix you are wasting your time corresponding with
Burson-Marstelar employee Hadron, a usenet troll
that is employed by the likes of Micoshaft and Appil
to post trolls into comp.os.linux.advocacy.

On 20 May 2012, 7 spake thusly:



I correspond with anyone if they have interesting things to say.
Occasionally even with you.



Yeah, right. Like MS is going to waste its money employing trolls to
post on dying media like cola. Like MS is going to do anything like this
at all rather than get their PR people to do it on their behalf.
(Astroturfing is a documented phenomenon, but it doesn't happen on
Usenet these days unless you're a bunch of losers for whom staff time is
free like the Scientologists: it happens on blogs.)

I understand your point.  

On the other hand, the "services" of a rat like "Hadron" can be bought
for a bottle of cheap wine.

Or we can just toss you a crispy creme chocolate donut.

Usenet is pretty much dying out.

Yea.
Many ISP's don't even carry it anymore or if they do it's a small
subset of groups.

It's another era in computing that will be gone in the not too
distant future.