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.

On 05/19/2012 07:34 PM, 7 wrote: [...]

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).

On 05/19/2012 08:57 PM, 7 wrote: [...]

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,

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

Not really, no.

Nope.

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.

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.

Usenet is pretty much dying out.

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

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.