[lkml]   [2008]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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.


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



Greg Ungerer -- Chief Software Dude EMAIL:
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB:

 \ /
  Last update: 2008-08-25 16:05    [W:0.063 / U:26.856 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site