You get the ability to memory map files. Handy for some tasks.
mmap() does work without an MMU.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclin
... you support __thread. the latter is just a keyword
to gcc to tell it to generate TLS relocs against the specified storage.
If the ggc-version is not constructed to support __thread, I don't think
you can tell it to do so, as gcc needs to know how to support __thread
(e.g. x86 uses reg
but most people are naturally a bit cautious
about touching GCC and Binutils, so it doesn't happen until someone is
really interested or is being paid to do that specific work.
As nowadays, more and more of the new archs do have MMU, I doubt we will
see much more non-MMU archs with theses fea
Mike Frysinger wrote:
On Friday 27 March 2009 14:26:57 Lennart Sorensen wrote:
On Fri, Mar 27, 2009 at 12:37:07PM -0400, Mike Frysinger wrote:
lies. there are no serious limitations at all with FDPIC ELF. it is
functionality equivalent to ELFs running under a MMU.
Well I haven't looked at FD
Lennart Sorensen wrote:
> > you can memory map files without a MMU
>
> How?
It's limited, but everything I could get to work, works. See:
Documentation/nommu-mmap.txt
David
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman
2009/3/27 Mike Frysinger :
> On Friday 27 March 2009 12:15:57 Lennart Sorensen wrote:
>> You also get fork(). That's a big deal to a lot of code. Fork requires
>> being able to copy an address space (preferably efficiently), which an
>> MMU can help you do. It might be possible to do without an
On Friday 27 March 2009 15:37:31 Jamie Lokier wrote:
> Thomas Häberle wrote:
> > All used CPUs have a MMU, but it is not used due to performance
> > reasons as the developers state. Someone threw a number into the
> > discussion and said enabling the MMU would cause performance losses
> > of about
Sujit Karataparambil wrote:
> Is it disabled in the proprietary operating system. It is an misnomer
> that MMU Slows down the embedded application.
> Certainly debatable.
>
> The key issue is do you have enough memory to turn on the MMU. Say an
> 4K Memory to 256M Memory the requirements are
> dif
Michael Schnell wrote:
>
> >So, only looking at processing power is only half of the story.
> Agreed !
>
> Even there is no real technical cause for this, most non-MMU Linux
> implementations seem not to support several important features needed
> for doing multithreaded: TLS, NPTL, "__tread"
Thomas Häberle wrote:
> All used CPUs have a MMU, but it is not used due to performance
> reasons as the developers state. Someone threw a number into the
> discussion and said enabling the MMU would cause performance losses
> of about 30-40 percent, thus if we switch to Linux at all it would
> h
On Friday 27 March 2009 15:29:20 Jamie Lokier wrote:
> Lennart Sorensen wrote:
> > > lies. there are no serious limitations at all with FDPIC ELF. it is
> > > functionality equivalent to ELFs running under a MMU.
> >
> > Well I haven't looked at FDPIC ELF since it doesn't work on m68knommu
> > ye
Lennart Sorensen wrote:
> > lies. there are no serious limitations at all with FDPIC ELF. it is
> > functionality equivalent to ELFs running under a MMU.
>
> Well I haven't looked at FDPIC ELF since it doesn't work on m68knommu yet.
>
> > you cannot do fork() without virtual memory since both
On Friday 27 March 2009 14:26:57 Lennart Sorensen wrote:
> On Fri, Mar 27, 2009 at 12:37:07PM -0400, Mike Frysinger wrote:
> > lies. there are no serious limitations at all with FDPIC ELF. it is
> > functionality equivalent to ELFs running under a MMU.
>
> Well I haven't looked at FDPIC ELF since
memory protection is not strictly part of the MMU. some processors
implement
MPU's (like the Blackfin processor) and the kernel supports it just fine.
that gets you standard data/instruction rwx control.
OK, I had never heard of it done that way before. That's neat.
Certainly not typical of a
On Fri, Mar 27, 2009 at 12:37:07PM -0400, Mike Frysinger wrote:
> there are processors which implement other features that people consider part
> of the MMU (like protection). virtual memory is the most significant feature.
Sure.
> lies. there are no serious limitations at all with FDPIC ELF.
On Friday 27 March 2009 12:15:57 Lennart Sorensen wrote:
> On Fri, Mar 27, 2009 at 08:39:57AM +0100, Thomas H?berle wrote:
> > A client is currently considering to switch Linux as operating system on
> > his devices. In a recent discussion the theme "virtual memory & MMU
> > usage" came up. All use
On Fri, Mar 27, 2009 at 08:39:57AM +0100, Thomas H?berle wrote:
> A client is currently considering to switch Linux as operating system on his
> devices.
> In a recent discussion the theme "virtual memory & MMU usage" came up.
> All used CPUs have a MMU, but it is not used due to performance reaso
On Friday 27 March 2009 06:53:15 David Howells wrote:
> Michael Schnell wrote:
> > Even there is no real technical cause for this, most non-MMU Linux
> > implementations seem not to support several important features needed for
> > doing multithreaded: TLS, NPTL, "__tread" keyword in C, really use
Michael Schnell wrote:
> Even there is no real technical cause for this, most non-MMU Linux
> implementations seem not to support several important features needed for
> doing multithreaded: TLS, NPTL, "__tread" keyword in C, really user space
> based FUTEX.
TLS, NPTL and userspace FUTEX are all
> All used CPUs have a MMU, but it is not used due to performance reasons as
> the developers state.
> Someone threw a number into the discussion and said enabling the MMU would
> cause performance losses of about 30-40 percent, thus if we >switch to Linux
> at all it would have to be ucLinux.
So, only looking at processing power is only half of the story.
Agreed !
Even there is no real technical cause for this, most non-MMU Linux
implementations seem not to support several important features needed
for doing multithreaded: TLS, NPTL, "__tread" keyword in C, really user
space bas
If there are many context switches, cache flushing/reloading is the main cause
of slowdown. The exact amount of slowdown depends on your application.
No need for cache flushing when switching the context with "decent"
cache designs (like x86).
-Michael
___
Thomas,
On Friday 27 March 2009 08:39:57 Thomas Häberle wrote:
> A client is currently considering to switch Linux as operating system on
> his devices. In a recent discussion the theme "virtual memory & MMU usage"
> came up. All used CPUs have a MMU, but it is not used due to performance
> reason
]
On Behalf Of Michael Schnell
Sent: Friday, March 27, 2009 9:48 AM
To: uClinux development list
Subject: Re: [uClinux-dev] MMU trade-off
> Someone threw a number into the discussion and said enabling the MMU would
> cause performance losses of about 30-40 percent, thus if we switch to
Someone threw a number into the discussion and said enabling the MMU would
cause performance losses of about 30-40 percent, thus if we switch to Linux at
all it would have to be ucLinux.
uCLinux does not mean "without MMU". uCLinux does support several
architectures with MMU.
The numbers
Hello!
A client is currently considering to switch Linux as operating system on his
devices.
In a recent discussion the theme "virtual memory & MMU usage" came up.
All used CPUs have a MMU, but it is not used due to performance reasons as the
developers state.
Someone threw a number into the di
26 matches
Mail list logo
