diff --git a/Documentation/NuttXDemandPaging.html b/Documentation/NuttXDemandPaging.html index d6a6c340c3..cf4bb0ce42 100755 --- a/Documentation/NuttXDemandPaging.html +++ b/Documentation/NuttXDemandPaging.html @@ -30,7 +30,19 @@
+ NuttX Common Logic Design Description + | +|
Initialization |
Page Faults |
Fill Initiation |
Fill Complete |
Task Resumption | @@ -96,15 +90,72 @@
+ Architecture-Specific Support Requirements + | +|
+ | + Memory Organization + | +
+ | + Architecture-Specific Functions + | +
- Terminolgy+Introduction |
+ This document summarizes the design of NuttX on-demand page. + This feature permits embedded MCUs with some limited RAM space to execute large programs some some non-random access media. + This feature was first discussed in this email thread: + http://tech.groups.yahoo.com/group/nuttx/message/213. +
++ What kind of platforms can support NuttX on-demang paging? +
+ If the platforms meets these requirement, then NuttX can provide on-demand paging: + It can copy .text from the large program in non-volatile media into RAM as needed to execute the huge program from the small RAM. +
+ +g_waitingforfill
- Initialization+NuttX Common Logic Design Description |
The following declarations will be added.
include/nuttx/page.h
and include/nuttx/arch.h
.
-
- Page Faults- |
-
Page fault exception handling. @@ -184,7 +232,7 @@ Sanity checking. This function will ASSERT if the currently executing task is the page fill worker thread. The page fill worker thread is how the the page fault is resolved and all logic associated with the page fill worker - must be "locked" and always present in memory. + must be "locked" and always present in memory.
pg_miss()
must be "locked" in memory.
+ The pg_miss()
must be "locked" in memory.
Calling pg_miss()
cannot cause a nested page fault.
@@ -266,13 +300,7 @@
-
- Fill Initiation- |
-
The page fill worker thread will be awakened on one of two conditions: @@ -298,48 +326,49 @@ That function will perform the following operations:
up_allocpage(vaddr, &page)
.
- This chip-specific function will set aside page in memory and map to virtual address (vaddr).
+ Call the architecture-specific function up_checkmapping()
to see if the page fill
+ still needs to be performed.
+ In certain conditions, the page fault may occur on several threads and be queued multiple times.
+ In this corner case, the blocked task will simply be restarted (see the logic below for the
+ case of normal completion of the fill operation).
+ up_allocpage(tcb, &vpage)
.
+ This chip-specific function will set aside page in memory and map to virtual address (vpage).
If all pages available pages are in-use (the typical case),
this function will select a page in-use, un-map it, and make it available.
- up_fillpage(page, pg_callback)
.
- This will start asynchronous page fill.
- The page fill worker thread will provide a callback function, pg_callback
,
- that will be called when the page fill is finished (or an error occurs).
- This callback will probably from interrupt level.
- up_fillpage(page, pg_callback)
.
+ This will start asynchronous page fill.
+ The page fill worker thread will provide a callback function, pg_callback
,
+ that will be called when the page fill is finished (or an error occurs).
+ This callback will probably from interrupt level.
+
While the fill is in progress, other tasks may execute.
If another page fault occurs during this time, the faulting task will be blocked and its TCB will be added (in priority order) to g_waitingforfill
.
But no action will be taken until the current page fill completes.
- NOTE: The IDLE task must also be fully locked in memory.
+ NOTE: The IDLE task must also be fully locked in memory.
The IDLE task cannot be blocked.
It the case where all tasks are blocked waiting for a page fill, the IDLE task must still be available to run.
- The chip-specific functions, up_allocpage(vaddr, &page)
and up_fillpage(page, pg_callback)
+ The chip-specific functions, up_allocpage(tcb, &vpage)
and up_fillpage(page, pg_callback)
will be prototyped in include/nuttx/arch.h
- Fill Complete- |
-
When the chip-specific driver completes the page fill, it will call the pg_callback()
that was provided to up_fillpage
.
pg_callback()
will probably be called from driver interrupt-level logic.
The driver ill provide the result of the fill as an argument.
- NOTE: pg_callback()
must also be locked in memory.
+ NOTE: pg_callback()
must also be locked in memory.
When pg_callback()
is called, it will perform the following operations:
@@ -356,13 +385,7 @@
- Task Resumption- |
-
When the page fill worker thread is awakened and g_pendingfill
is non-NULL (and other state variables are in concurrence),
@@ -412,6 +435,197 @@
+ Architecture-Specific Support Requirements+ |
+
+ Chip specific logic will map the virtual and physical address spaces into three general regions: +
pg_miss()
that is called from the page fault handler.
+ It also includes the pg_callback()
function that wakes up the page fill worker thread
+ and whatever chip-specific logic that calls pg_callback()
.
+ + This memory organization is illustrated in the following table. + Notice that: +
SRAM | +Virtual Address Space | +Non-Volatile Storage | +
---|---|---|
+ | DATA | ++ |
+ | Virtual Page n (n > m) | +Stored Page n | +
+ | Virtual Page n-1 | +Stored Page n-1 | +
DATA | +... | +... | +
Physical Page m (m < n) | +... | +... | +
Physical Page m-1 | +... | +... | +
... | +... | +... | +
Physical Page 1 | +Virtual Page 1 | +Stored Page 1 | +
Locked Memory | +Locked Memory | +Memory Resident | +
+ As an example, suppose that the size of the SRAM is 192Kb (as in the NXP LPC3131). And suppose further that: +
+ Then, the size of the locked, memory resident code is 32Kb (32 pages). + The size of the physical page region is 96Kb (96 pages), and the + size of the data region is 64 pages. + And the size of the virtual paged region must then be greater than or equal to (1024-32) or 992 pages (m). +
+ ++ Standard functions that should already be provided in the architecture port: +
+void up_block_task(FAR _TCB *tcb, tstate_t task_state);
+ void up_unblock_task(FAR _TCB *tcb);
+ + New, additional functions that must be implemented just for on-demand paging support: +
+ +int up_checkmapping(FAR _TCB *tcb);
+ up_checkmapping()
returns an indication that checks if the page fill still needs to performed or not.
+ In certain conditions, the page fault may occur on several threads and be queued multiple times.
+ This function will prevent the same page from be filled multiple times.
+ int up_allocpage(FAR _TCB *tcb, FAR void *vpage);
+ paddr
.
+ The size of a physical page is determined by the configuration setting CONFIG_PAGING_PAGESIZE
.
+ NOTE: This function must always return a page allocation.
+ If all pages available pages are in-use (the typical case), then this function will select a page in-use, un-map it, and make it available.
+ int up_fillpage(FAR _TCB *tcb, FAR const void *vpage, void (*pg_callback)(FAR _TCB *tcb, int result));
+ up_fillpage()
.
+ This will start asynchronous page fill.
+ The common logic will provide a callback function, pg_callback
, that will be called when the page fill is finished (or an error occurs).
+ This callback is assumed to occur from an interrupt level when the device driver completes the fill operation.
+
+