Date: Sun, 02 Apr 95 00:17:19 -0800 From: Bakul Shah <bakul@netcom.com> To: hackers@FreeBSD.org Subject: swap space (was Re: any interest?) Message-ID: <199504020817.AAA05418@netcom23.netcom.com>
next in thread | raw e-mail | index | archive | help
Swap space is another thing that is worth taking a fresh look at. Some things to consider.... - We no longer (or hardly ever) swap out entire process images like we used to. [`We' == all moderen Unixes] - Most of the traffic is paging traffic and (as far as I remember) the clock algorithm does not care for which page belongs to which process. - Many more page-ins occur, compared to page-outs. Optimizing swap placement to improve pagein times ought to help the overall performance. - Typically page-ins of different processes are not related. [except when they are used as a group -- but it is difficult to know at kernel level which processes constitute a cooperating group of processes.] - May be pages that constitute the working set of a process ought to be swapped together? The idea is that you will need them together and if a few are paged out the process will be blocked waiting for them. - Do we really need to preallocate all the swap space we may ever need? That seems like a poor use of space. - As long as there is backing store for the total amount of virtual space allocated, everyone can make progress. Beyond that why should the swap space resource be treated any different from normal files? - Perhaps a soft lower bound and hard upper bound for how much space can be used for swapping may be better? - Perhaps contiguous swap-space allocation *per* process may be good enough? - Unifying swap and file models ought to help each other. For instance, contiguous and/or pre-allocation of files can be useful for certain applications. Conversely, growing a swap space can be useful too. Also, by keeping a swap-file per process, you can use all the standard tools on them (+ follow the standard protection model). - Fundamentally there is nothing different about swap space compared to a normal file. One can think of a typical Unix process image as consisting of a numbe of files (or file segments): text, data, bss & stack. My opinions & ideas (+ some ideas borrowed from others). I throw them out to stir up some interesting discussion. -- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504020817.AAA05418>