Hi all, apologies if this has been covered somewhere but I couldn't see it anywhere in the manual or on the forum. How would forwardcom handle paging to disk if the system runs out of memory given that it doesn't use pages? Would the operating system have to edit the table of memory blocks for the process being paged? The other solution I can think of would be to just assume that this case is rare enough that it can be dealt with by raising an out of memory exception, but that has the problem that whether a program encounters such an exception would be affected by the other programs running on the system when one of the major advantages of an operating system is that a program can usually be written as if it has exclusive use of the system.
Best wishes,
Tim
Handling paging without a page system
Moderator: agner
Re: Handling paging without a page system
There are no fixed-size pages. The OS would have to make an arbitrary-size entry in the memory map for a block of memory that has been swapped to disk.
-
HubertLamontagne
- Posts: 80
- Joined: 2017-11-17, 21:39:51
Re: Handling paging without a page system
Presumably, the OS would need to use something like Buddy Memory Allocation system-wide to keep allocations contiguous as much as possible and to limit the number of mappings (and to be able to do multiple hundred megabyte allocations at all). Excessively large mappings that get swapped to disk would probably get split.
As soon as the number of mappings grows over the hardware limit, the least recently used mappings are evicted. Whenever the evicted mappings are used, a page fault happens, which allows the OS to swap the evicted mappings back in (by evicting other mappings). This turns the whole scheme into a software TLB.
Buddy Memory Allocation: https://en.wikipedia.org/wiki/Buddy_memory_allocation
A paper on software TLBs: http://cgi.cse.unsw.edu.au/~cs3231/11s1 ... -nagle.pdf
As soon as the number of mappings grows over the hardware limit, the least recently used mappings are evicted. Whenever the evicted mappings are used, a page fault happens, which allows the OS to swap the evicted mappings back in (by evicting other mappings). This turns the whole scheme into a software TLB.
Buddy Memory Allocation: https://en.wikipedia.org/wiki/Buddy_memory_allocation
A paper on software TLBs: http://cgi.cse.unsw.edu.au/~cs3231/11s1 ... -nagle.pdf
Re: Handling paging without a page system
I have a proposal regarding compatibility with software or hardware that uses paging:
Currently, the manual specifies that addresses in the memory map must be divisible by 8.
What do you all think about increasing this to a 4kb alignment?
As far as I am aware, almost all hardware which uses paging has a size of 4kb for the smallest page. If we increase the alignment to this size, a variable size memory segment could be expressed as an amount of contiguous pages.
Translation from pages to a variable sized segment is pretty easy, the only non-trivial part I can think of being merging contiguous pages to a single segment. Of course, trashing the memory map with non-contiguous pages is still a possibility if not carefully managed.
Translating from a segment to pages would pose a problem if the size of a segment is not the multitude of the smallest page size. Pages would be able to cross segment boundaries, posing a security problem and/or requiring extensive virtualization mechanisms. This can be avoided with my proposal.
As a side-effect, cache lines would also no longer be able to cross segment boundaries.
The obvious downside is potentially wasted memory space at the end of a segment. Considering the low amount of segments, this should be a pretty insignificant amount and is still no downgrade from a paging system.
Currently, the manual specifies that addresses in the memory map must be divisible by 8.
What do you all think about increasing this to a 4kb alignment?
As far as I am aware, almost all hardware which uses paging has a size of 4kb for the smallest page. If we increase the alignment to this size, a variable size memory segment could be expressed as an amount of contiguous pages.
Translation from pages to a variable sized segment is pretty easy, the only non-trivial part I can think of being merging contiguous pages to a single segment. Of course, trashing the memory map with non-contiguous pages is still a possibility if not carefully managed.
Translating from a segment to pages would pose a problem if the size of a segment is not the multitude of the smallest page size. Pages would be able to cross segment boundaries, posing a security problem and/or requiring extensive virtualization mechanisms. This can be avoided with my proposal.
As a side-effect, cache lines would also no longer be able to cross segment boundaries.
The obvious downside is potentially wasted memory space at the end of a segment. Considering the low amount of segments, this should be a pretty insignificant amount and is still no downgrade from a paging system.