OSDev.org

First of all I apologize for any essence-of-noob this post may contain.
would it be logical to have a paging system that rather than having a set amount of paged hdd space, had a paging system that would adjust to the programs needs by allowing the application to say at execution? is this possible? or am i just completely wrong about everything and fail at life:)

Hi,

Apologies for any patronising comments contained in this post - by your post it's not possible for me to tell at exactly what level you are at.

You mention "paged hdd space" - I should point out that paging and virtual memory in general has nothing to do with the hard disk drive at all.

It is possible that you're being confused by windows' terminology, where it describes its swapspace or pagefile as "virtual memory".

A virtual address space (or "virtual memory" in the technical sense) is an imaginary address space, not limited by how much physical RAM you have in your system. This virtual address space is split up into 'pages', which the CPU's MMU maps to 'frames' of the same size in the physical address space, which may mean RAM (note that many architectures use memory-mapped I/O, which means not all of its physical address space is taken up by RAM), by a system of page tables or raw TLB entries, depending on your architecture.

In most implementations, each process has its own virtual address space, so that they are independent of each other. Furthermore, normally the operating system's code, stacks, data and heap are mapped in every address space at a specific location, so the OS can swap between address spaces as it likes during execution without side effect.

This leaves a certain chunk of the virtual address space available for program use - on x86_32 systems this is usually between 2GB - 3GB, depending on the operating system in question.

The application may do whatever it likes in that 2GB - It will be loaded by the operating system at whatever address it is statically linked to, and all shared libraries it depends on will be loaded and relocated in that chunk too.

The code, data and bss sections are all fixed in size, there is no way to extend them, however most libraries provide a heap, that is dynamically expandable. There is also in most systems (and the heap may even be implemented this way) the possibility of mapping arbitrary chunks of memory. The UNIX mmap() syscall allows you to do just that.

So under most systems, user programs are far from statically limited - they have at least 2GB of address space to play with!

Hope this helps,

James

Well ... but assuming that you do mean the swapspace for the virtual memory system ...

The swapspace gets activated when the physical memory manager runs out of physical memory pages to store all the virtual memory pages in. Most OSes hide this level of detail from userspace programs. So, in many OSes, no userspace program would have any way to know how much physical memory is left. They might also have trouble guessing how much virtual memory they are about to use, if the amount of available physical memory is zero, for example.

But there are nano- and exo-kernels being developed here, that do not have physical memory managers. Userspace applications are supposed to do their own physical and virtual memory management when running on these operating systems -- and to do their own pageswapping to disk, if needed.

So, if you want to have your userspace apps doing such things, it can make an enormous design impact on your OS -- because you can then design with a goal of a nano- or exo-kernel.

ok thanks and again sorry for the confusion

On the topic of resizing swap files on the fly (which I think is what you're asking) then it depends on how you implement your swap files. Most operating systems, AFAIK, store the actual lba address of the swap file on the hard drive within the swap code, so all the swap code needs is a basic hard disk driver and this magic information. In other words, the filesystem driver is not called on each swap. This reduces complexity (so the swap algorithm requires less memory and is less likely to run out of memory at a time when memory is, by definition, low) and also increases the speed of swaps.

If you implement a swap file to be dynamically resizeable, then you have problems with what to do about the other files on your partition when there is no free space beyond the end of the swap file to expand into. You could have the swap file managed by the file system, so it can expand by becoming fragmented, but then you need to have the swap code rely on your filesystem driver. On the other hand, you could put the swap code to sleep for a bit and then copy the contents of the swap file to a larger free contiguous area of the disk and then update the lba address in the swap code (which I think is how Windows does it). Linux just uses a separate swap partition, so resizing is impossible but its easy to obtain lba addresses for the start/end of the partition and you don't need to worry about the file becoming fragmented.

Regards,
John.