Why does Linux need memory management units and cache?

[7]

Why does Linux need memory management units and cache?
------------------------------------------------------

Excuse us, this is bothering me much.

Why does Linux need memory management units and cache?

[Niklas Holsti]

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.

> and cache?

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.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

[7]

Niklas Holsti wrote:

> On 12-05-19 15:40 , 7 wrote:
>> Why does Linux need memory management units and cache?
>> ------------------------------------------------------
>>
>> Excuse us, this is bothering me much.
>>
>> Why does Linux need memory management units
>
> To implement virtual address spaces for processes.

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.

> 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.
>
>> and cache?
>
> 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.

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.

[Piergiorgio Sartor]

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

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

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.

> So a cache could be implemented in software. And if done properly

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,

--

piergiorgio

[7]

Piergiorgio Sartor wrote:

> On 05/19/2012 07:34 PM, 7 wrote:
> [...]
>> 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.
>
> 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.

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.

>> So a cache could be implemented in software. And if done properly
>
> 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.

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

[Piergiorgio Sartor]

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

>> It is faster, also faster to crash, since programs
>> could, -intentionally or unintentionally-, address
>> memory which they should not.
>
> 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.

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.

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

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

[...]

>> 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.
>
> A cache could be more effective if smart
> software precisely keeps tabs on what
> the DMA controller is doing; and programs that

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.

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

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.

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

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,

--

piergiorgio

[Grant Edwards]

On 2012-05-19, 7 <email_at_www_at_en...@enemygadgets.com> wrote:
> Niklas Holsti wrote:
>
>> On 12-05-19 15:40 , 7 wrote:
>>> Why does Linux need memory management units and cache?
>>> ------------------------------------------------------
>>>
>>> Excuse us, this is bothering me much.
>>>
>>> Why does Linux need memory management units
>>
>> To implement virtual address spaces for processes.
>
> Virtual address space in a nut shell means program counter relative
> operation.

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

>> 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.
>
> So a cache could be implemented in software.

Not really, no.

> And if done properly with a fast program, it should run faster and
> better than hardware

Nope.

> which would use up a lot more software in setting up and managing a
> cache.

--
Grant

[Hadron]

Grant Edwards <inv...@invalid.invalid> writes:

> On 2012-05-19, 7 <email_at_www_at_en...@enemygadgets.com> wrote:
>> Niklas Holsti wrote:
>>
>>> On 12-05-19 15:40 , 7 wrote:
>>>> Why does Linux need memory management units and cache?
>>>> ------------------------------------------------------
>>>>
>>>> Excuse us, this is bothering me much.
>>>>
>>>> Why does Linux need memory management units
>>>
>>> To implement virtual address spaces for processes.
>>
>> Virtual address space in a nut shell means program counter relative
>> operation.
>
> No, that's not what virtual address space means.

"7" is a COLA troll. He claims to have written a transaction manager
using the VB clone "gambas" with a mysql server that can monitor and
process ALL the words financial transactions in real time. Apparently
its under the GPL. He's a an idiot.

>
>>> 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.
>>
>> So a cache could be implemented in software.
>
> Not really, no.

Although caches can and are implemented in SW at times. In this case he
is, of course, way off the mark and talking bullshit. His real name is
Michael Joseph and he also claims to be the European Inventor of the
year.

>
>> And if done properly with a fast program, it should run faster and
>> better than hardware
>
> Nope.

As you can see, he's delusional as well as technicall inept.

>
>> which would use up a lot more software in setting up and managing a
>> cache.

Another cracker from "7" is that "using the power of Linux" he thinks he
can write "in assembler" an access path to a distributed multi table
rdbms record using on the fly selection parameters so thats its orders
of magnitude faster than using the well configured sql access path. In
short : he's a fucking idiot.

[Nix]

On 20 May 2012, Hadron told this:

> Grant Edwards <inv...@invalid.invalid> writes:
>
>> On 2012-05-19, 7 <email_at_www_at_en...@enemygadgets.com> wrote:
>>> Virtual address space in a nut shell means program counter relative
>>> operation.
>>
>> No, that's not what virtual address space means.

It was interesting to me to learn that the majority of the binaries on
one of my machines, being non-PIC, were running directly on the
1:1-mapped physical memory. I was sure I had virtual memory on that
machine.

> "7" is a COLA troll. He claims to have written a transaction manager
> using the VB clone "gambas" with a mysql server that can monitor and
> process ALL the words financial transactions in real time. Apparently
> its under the GPL. He's a an idiot.

Well, that does depend what the 'processing' is. If it's simple enough,
maybe, but I doubt that all the world's financial transactions will even
fit down one pipe or reasonably-sized set of pipes anymore. Clearly 7
wrote this program in 1970 with the aid of a time machine or doesn't
know just how many trades are executed per day these days.

>>>> 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.
>>>
>>> So a cache could be implemented in software.
>>
>> Not really, no.
>
> Although caches can and are implemented in SW at times.

Caches, yes: I've implemented more than a few myself. The sorts of cache
that sit between the CPU and the RAM can be software-invalidated or
software-tagged but cannot be *implemented* in software. (It would
perhaps be possible to design a system where the cache was controlled
with FPGA logic, thus sort of halfway to software, but that's the
closest you could get I think. To my knowledge nobody has done this,
because it would be both expensive and nearly useless.)

>>> which would use up a lot more software in setting up and managing a
>>> cache.

What does "use up a lot more software" even *mean*? (He clearly hasn't
looked at e.g. the Linux kernel, on which platforms with
software-tagged, software-invalidated or, God forbid, VIPT caches have
*way* more annoying thrashing-about with cache management logic than a
platform with saner semantics like x86 does. FWIW this is the first time
I've ever called x86 sane in any aspect of its design.)

> Another cracker from "7" is that "using the power of Linux" he thinks he
> can write "in assembler" an access path to a distributed multi table
> rdbms record using on the fly selection parameters so thats its orders
> of magnitude faster than using the well configured sql access path. In
> short : he's a fucking idiot.

Well, that's just extreme cluelessness and a massive case of the
Dunning-Kruger effect, I suspect. And/or outright trolling, I suppose,
cola being where old trolls retire to die.

--
NULL && (void)

[7]

Piergiorgio Sartor wrote:

> On 05/19/2012 08:57 PM, 7 wrote:
> [...]
>>> It is faster, also faster to crash, since programs
>>> could, -intentionally or unintentionally-, address
>>> memory which they should not.
>>
>> 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.
>
> 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.

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.

[7]

Nix wrote:


> It was interesting

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.

[Nix]

On 20 May 2012, 7 spake thusly:

> Nix wrote:
>
>> It was interesting
>
> Nix you are wasting your time corresponding with
> Burson-Marstelar employee Hadron, a usenet troll

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

> that is employed by the likes of Micoshaft and Appil
> to post trolls into comp.os.linux.advocacy.

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

--
NULL && (void)

[chrisv]

Nix wrote:

> 7 spake thusly:

>>
>> Nix you are wasting your time corresponding with
>> Burson-Marstelar employee Hadron, a usenet troll
>
>I correspond with anyone if they have interesting things to say.
>Occasionally even with you.
>
>> that is employed by the likes of Micoshaft and Appil
>> to post trolls into comp.os.linux.advocacy.
>
>Yeah, right. Like MS is going to waste its money employing trolls to
>post on dying media like cola.

I understand your point.

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

--
"If you were to lose your irrational hatred of Windows & MS then you'd
be a good advocate as to being merely another anti-MS nutter." -
"True Linux advocate" Hadron Quark

[GreyCloud]

On 5/21/2012 9:44 AM, chrisv wrote:
> Nix wrote:
>
>> 7 spake thusly:
>>>
>>> Nix you are wasting your time corresponding with
>>> Burson-Marstelar employee Hadron, a usenet troll
>>
>> I correspond with anyone if they have interesting things to say.
>> Occasionally even with you.
>>
>>> that is employed by the likes of Micoshaft and Appil
>>> to post trolls into comp.os.linux.advocacy.
>>
>> Yeah, right. Like MS is going to waste its money employing trolls to
>> post on dying media like cola.
>
> 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.

[GreyCloud]

Usenet is pretty much dying out.

[Foster]

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.