On Sun, Jun 23, 2013 at 3:46 AM, Chris Johns <chr...@rtems.org> wrote:
> Thomas Dörfler wrote: > >> >> please note that some PPC derivatives (especially those for embedded >> projects) usually have eight DBATs and eight IBATs. This feature must be >> enabled (e.g. in a 603e core) with a special bit in one of the HID >> registers, but it will put the number of BAT ranges closer to what is >> needed in embedded computing. >> > > Yes this is currently true. I also see an emerging range of applications > where dynamic control of memory is important. > > > The advantage of BATs versus pages is definitively, that they usually >> get set up ONCE during startup and, due to their flexible size, will not >> need to be reloaded. >> > > I understand this is important for some applications. I have used VM and > MMU features in application specific ways dating back to the 68010 (68070) > where the use was dynamic. > > > Note that the pages usually only cover 4K of >> memory, and the "translation lookaside buffer" (TLB) only maintains the >> last 16-64 used pages, >> > > The ARM which I am currently using and have handy seems to support 1MB, > 64K and 4K ranges depending on the TLB table level used. I would be > surprised if an entry was needed for each page in use. > > Yes it ranges in ARM. Last year we implemented two-level page tables with set of possible page sizes, but it was discarded due to performance issue. The current libmm/ARM (arm920) code used one level 1 MB sections for protection. Also Sebastian implemented 1 MB sections for the new realview BSP. > > so there is always code involed reloading the >> required page info into the TLB. >> > > Are you sure ? I though this depended on the set up and configuration and > if the entries are locked or not. My view is the API is to provide access > to the available resources and if there is abuse it will result in the > situation you are suggesting. If the fault handler generates an error the > user will soon understand the limitation. > > > IMHO this reduces the realtime performance of the system. >> > > Yes it will if we attempt to implemented a full VM with fault handling, > however I am not sure this is the case if the number of TLB entries matches > the number the device can manage (cache). > > > >> In short: Supporting both (BATs and pages) in libmm would be a good >> feature. >> >> > I agree with Gedare comments and approach, at the low level yes fine and > what happens at the API I am not sure. > > That's OK, there is already an interface for handling BAT. Now it's about how to choose between BAT and pages. > > Chris > ______________________________**_________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel> >
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
