Re: On-demand paging and lazy loading on NuttX;
On 1/24/2024 3:44 PM, Gregory Nutt wrote: The on-demand paging logic is obsolete and incomplete as well as incorrect for the current architecture. It was an experiment only for the LPC3131 when I was running out of a small SRAM with dynamic paging from SPI flash. It really should be removed. True on-demand paging as you envision should be implemented in the context of the kernel build mode (which did not exist in the time frame of the LPC3131) which already supports dynamic paging of the heap, but not the stack or instruction space. There is also: https://cwiki.apache.org/confluence/display/NUTTX/On-Demand+Paging There is also this better reference: https://cwiki.apache.org/confluence/display/NUTTX/Memory+Configurations . It address both the on-demand paging featured (briefly) and compares this to Kernel mode (in depth).
Re: On-demand paging and lazy loading on NuttX;
The on-demand paging logic is obsolete and incomplete as well as incorrect for the current architecture. It was an experiment only for the LPC3131 when I was running out of a small SRAM with dynamic paging from SPI flash. It really should be removed. True on-demand paging as you envision should be implemented in the context of the kernel build mode (which did not exist in the time frame of the LPC3131) which already supports dynamic paging of the heap, but not the stack or instruction space. There is also: https://cwiki.apache.org/confluence/display/NUTTX/On-Demand+Paging On 1/24/2024 2:14 PM, Tiago Medicci Serrano wrote: Hi! The topic is *on-demand paging and "lazy loading" on NuttX*. Well, the on-demand paging article <https://nuttx.apache.org/docs/latest/components/paging.html> (and ` CONFIG_PAGING <https://github.com/apache/incubator-nuttx/blob/90f24ec29d0731cdda4b1db14ec73a87d88c50bf/arch/Kconfig#L888>`) seems to have implemented the dynamic loading of instruction sections (*.text) from a non-volatile media to internal RAM (able to execute instructions). This was done mainly for LPC31xx and stated that it isn't complete yet (a kind of experiment) and it does contain a page fault handling logic. On the other hand, one could use the Shared Memory Support <https://nuttx.apache.org/docs/latest/components/mm/shm.html> mechanism of paging allocation to implement on-demand paging. It even states that: NOTE: An improved implementation my perform a “lazy” back up of the physical memory, i.e., do not allocate the physical memory until the memory is required, for example, when a page fault occurs when a application tries to allocate the memory. But lacks the "page fault" mechanism to provide a newly mapped page for the task that caused the exception. I may be missing something about this subject, but have you thought about it? The idea is to allocate bigger virtual memory to the tasks' stack (with few mapped pages) and treat page fault exceptions when they occur (and freeing physical memory when it isn't needed anymore, making it possible to be mapped to other pages if needed). How far are we from providing that? Any thoughts about it? Best regards,
On-demand paging and lazy loading on NuttX;
Hi! The topic is *on-demand paging and "lazy loading" on NuttX*. Well, the on-demand paging article <https://nuttx.apache.org/docs/latest/components/paging.html> (and ` CONFIG_PAGING <https://github.com/apache/incubator-nuttx/blob/90f24ec29d0731cdda4b1db14ec73a87d88c50bf/arch/Kconfig#L888>`) seems to have implemented the dynamic loading of instruction sections (*.text) from a non-volatile media to internal RAM (able to execute instructions). This was done mainly for LPC31xx and stated that it isn't complete yet (a kind of experiment) and it does contain a page fault handling logic. On the other hand, one could use the Shared Memory Support <https://nuttx.apache.org/docs/latest/components/mm/shm.html> mechanism of paging allocation to implement on-demand paging. It even states that: > NOTE: An improved implementation my perform a “lazy” back up of the > physical memory, i.e., do not allocate the physical memory until the memory > is required, for example, when a page fault occurs when a application tries > to allocate the memory. > But lacks the "page fault" mechanism to provide a newly mapped page for the task that caused the exception. I may be missing something about this subject, but have you thought about it? The idea is to allocate bigger virtual memory to the tasks' stack (with few mapped pages) and treat page fault exceptions when they occur (and freeing physical memory when it isn't needed anymore, making it possible to be mapped to other pages if needed). How far are we from providing that? Any thoughts about it? Best regards, -- Tiago Medicci Serrano Embedded Software Engineer MSc Electronics/Microelectronics m: +55 (19) 981403886 <+55+(19)+981403886> e: tiago.medi...@gmail.com a: Campinas, Brazil Follow me: <https://www.linkedin.com/in/tiago-serrano-924458b6> <https://github.com/tmedicci>
