>
> On Thu, 26 Aug 1999, Bjorn Wesen wrote:
>
> > you can forget memory protection, but multitasking has nothing to do with
> > MM so that is no problem. the problem is how to implement the unix
> > semantics of fork(), and other MM tricks like demand loading and sharing
> > of text/data that support the multitasking model.
>
> Oh, yes, another trick uClinux uses (and could go a bit further with) is
> sharing everything that can be shared, never mind the abscence of an MMU.
> If .text is supposed to be read-only, we should only have to load it into
> RAM once. (Though, currently, we don't. If it's in ROM, we don't load it
> into RAM at all, of course.)
Note that the "magic ROM pointer" pointer stuff may be going away (it touches
too many files) I've not decided yet. In any case, for the 2.3.x port this
will not be needed to get ROM XIP :-)
>
> > you also need to either relocate all loaded text or compile it as position
> > independent code (since you can't put all segments at their original
> > VMA's). we relocate, i think uclinux uses PIC.
>
> PIC on 68000 devices, relocation on ColdFire, though that code isn't
> completely merged yet.
I'll release stuff RSN, it's merged in the new tree. It's a small change and
only affects binfmt_flat.c, and related header if you need it before hand on
68k
>
> > so to recap, the kernel itself is _comparatively_ easy to remove MM from,
> > compared to the problems you'll get with shared libraries, ill-behaved
> > programs, buggy programs, and programs that want to use fork() and MM.
Shared libs are not a problem, it's just a matter of implementing them.
But there is nothing fundamentally difficult about it.
...
> > oh yeah, one other big issue is memory fragmentation. you can't map
> > together pages spread in memory, you need consecutive pages for loading
> > executables etc. and it's no fun trying to allocate, say, 200 KB after
> > you've run a linux box for a while using page cache and buffer caches
> > spread all over memory.
>
> Correct. Well, some of this is moot (any cache that can be flushed will
> be, and I suspect that some of it which cannot be actually flushed could
> actually be defragmented.) But the problem is compounded by the fact that
> the current kernel allocator (power of 2 buddy system) is extremely bad
> for this sort of thing -- or so everybody tells me. I've not yet actually
> found a different implementation that I could try, nor an exact statement
> of how poor the buddy system is in practice compared to other techniques.
Really bad. It was not designed with contiguous regions in mind, keeps no
"slop" to allocate later, does aggregate blocks together... It is really
good for what it was designed for. We might be better off just using
a more tradional malloc() package.
>
> There's a whole suite of connected problems here. If he had swapping, we
> could swap program sections out to help defragment the system. Or, if we
No you can't, you'd have stale pointers left around (don't say mark
and sweep or compiler "glue":-)
> had some sort of allocation system based on handles instead of pointers
> then we could swap or move any unlocked handles. As I mentioned, I suspect
There, he said it... compiler glue ;^) No, I refuse ;^)
> some amount of movement of locked buffer-cache entries is already
> feasible, which would specifically benefit us because RAM disks are made
> out of locked buffer cache pages.
I think a more general blkmem will help here. We don't really care if the
ram disk returns buffers. Actually, this gives more potential for
fragmentation each time you free a block and go get another. Your memory
pattern is never going to be stable (which one typically expects to a
large extent in embedded systems) when freeing buffers. A ramdisk that
is a real block of memory is a real win, one less thing messing around
allocating memory. It would be interesing to see how much memory is
actually wasted because the the buffer cache has pages (which is an
imaginary concept without an MMU anyway) with pages between that
(almost) nothing can use...
>
> To some degree, the general problem can be limited by making one of the
> usual assumptions for embedded hardware: the device is special purpose,
> and is not intended to run an arbitrary set of programs.
This is not just an assumption. It is necessary for certain things,
like security for instance. Network enabled + arbitrary program +
no memory protection = Windows ;^)
>
> --
> Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)
>
>
--
Cheers,
Jeff / VE3DJF [EMAIL PROTECTED] http://www.cgocable.net/~jdionne
Got one, got one, everybody's got one. Oompah oompah, stick it up your jumper.
Got one, got one, everybody's got one. Oompah oompah, stick it up your jumper.
--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.
