[GSoC] BAT vs Pages on PowerPC [Please give a feedback]

[Hesham Moustafa]

On Sun, Jun 23, 2013 at 3:46 AM, Chris Johns <chrisj at 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 at rtems.org
> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130623/e5ade49c/attachment-0001.html>