Messages in this thread | | | Date | Tue, 26 Aug 2008 00:02:25 +1000 | From | Greg Ungerer <> | Subject | Re: [PATCH 00/10] AXFS: Advanced XIP filesystem |
| |
Hi Jamie,
Jamie Lokier wrote: > Greg Ungerer wrote: >> Sort of. It actually just uses a single ->read to bring in >> the entire file contents. There is a few limitations on the use >> of mmap() for non-mmu. Documentation/nommu-mmap.txt gives >> more details. With no MMU it does rely on being able to kmalloc() >> a single RAM region big enough to hold the entire file. > > That's unfortunate, if you're using FDPIC-ELF or BFLT-XIP, you really want > to kmalloc() one region for code (i.e. mmap not the whole file), and > one separate for data.
That is what the BFLT loader does. For the XIP case it mmap()s the text directly from the file, and then mmap()s a second region for the data/bss (reading the data into that region).
I was referring to general mmap() of a file case above, not the exec path.
> Asking for a single larger region sometimes > creates much higher memory pressure while kmalloc() attempts to > defragment by evicting everything.
Sure.
> But that's fiddly to do right in general. > > The natural thing for AXFS to do to support no-MMU FDPIC-ELF or > BFLT-XIP is store the code segment uncompressed and contiguous, and > the data segment however the filesystem prefers, and the profiling > information to work out where these are is readily available from the > mmap() calls, which are always the same when an executable is run.
Yep.
Regards Greg
------------------------------------------------------------------------ Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
| |