On Thursday, August 26, 2010 18:45:08 Steve Longerbeam wrote: > On 08/26/2010 12:04 PM, Mike Frysinger wrote: > > On Thursday, August 26, 2010 14:19:41 Steve Longerbeam wrote: > >> The ARM MPU can do something similar. MPU regions can overlap, and a > >> simple priority scheme is used to decide which region's permissions > >> apply to a memory access that overlaps (higher numbered regions have > >> higher priority). So on ARM we can "lock" a PTE/region, by defining > >> region 0 to cover the entire address space, and give kernel read/write > >> access, user no access. And region 0 is never overwritten or disabled. > >> So if an access is made to an address not described by any other region, > >> region 0 permissions are applied to the access (and a protection fault > >> is generated if the access was made in user mode). > >> > >> Note that, with region 0 locked, that only leaves 7 PTEs/regions that > >> can be swapped in and out for user processes. So with the ARM MPU, we > >> can't create a region for every mmap(), we would run out of available > >> entries. So we have to use a trade-off, only create an MPU region for > >> XIP file mappings (text). All other mappings (non-XIP file mappings and > >> anonymous mappings) allocate from a common user memory pool (which is > >> another patch I plan to submit). > > > > i dont understand why running out of entries is a problem. we run out of > > entries too as you cant cover 512MiB of SDRAM with 16 entries. we simply > > take an exception when this occurs and in the exception handler, we use > > a basic round-robin replacement scheme to install a valid PTE (assuming > > of course the user has a valid mapping for the excepting address). then > > we return to the user process and it continues on. > > > > why wont this scheme work for you too ? > > no, you're right, that would work. Of course, it would have a bigger > memory usage for the page tables, and a performance hit (with my > implementation when a process is running there are no faults). But it is > more inline with how MMU kernels work, and it adds process-to-process > protection too.
we used a bitmap to save on memory and execution. each bit representing a 4k chunk. this is the "page_rwx_mask" and similar stuff that appears in the Blackfin asm/mmu*.h headers. have you done performance measurements to see the overhead with the MPU turned on in your scheme compared to off ? doing something like a ffmpeg decode to another file. if the performance trade offs of your current scheme (per- mapping) is significant compared to the classic per-page, then it is worth while to extend the MPU Kconfig option so people can select per-page or per- mapping schema. btw, i dont think it was mentioned earlier, but these ranges you're working with ... do they have alignment requirements ? the thing about Blackfin PTEs is that they must be aligned according to the size they represent. so if it is a 4KiB mapping, it must be aligned to 4KiB. if it's 1MiB, it must be aligned to 1MiB. it'd be nice if that alignment restriction wasnt there as we could then do a flexible range mapping similar to what you have. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
