The Linux pageing-out code works v. well under most conditions.
It also has the benefits of being; simple :), portable between
architectures, and well written.
On Tue, 19 Nov 1996, Jean Francois Martinez wrote:
> Wishes for memory management in 2.1
> First: Real swapping. When two processes are fighting for memory and
> memory is tight only way to make progress is freezing one of them and
> let the other run unimpeded for a few seconds.
I'm not a fan of swapping out an entire process (is this what you mean?)
It adds a lot of extra problems into the kernel (and hence more code),
espically to the scheduler. While I hate to suggest someone spends
money, if your system is thrashing the disk because of paging-out then
you really should consider a few extra megas.
> Second: Linux does not write to swap, pages who have never been
> modified like code pages. This way Linux does not lose time wring
> them. But because reading from swap is faster I think when a page is
> being recalled for thez upteemth time it would be wise to write it to
> swap. We will get it faster next times. However it seems it would
> greatly complicate the code so perhaps it is not a good idea. (Of
> course this does not apply to pages we are dicarding to make a hole
> for DMA).
Yes, it is faster (not sure how much fatser), but it also a good way of
eating a lot of swap space. If implemented it could be made an option.
(Marking the pages of a file that are on swap but no longer referenced
isn't too difficult, but making the kernel take advantage of the fact is
- well, it isn't non-trival, espcially if you consider writing to the
file).
(Please correct me if I'm wrong), but modern Unix OS don't use swap for
named pages. I known SCO doesn't, and fairly sure UnixWare doesn't.
Although that's no reason why Linux shouldn't if someone can prove its
worth while.
A few months ago, I spent some time trying to work out a re-write of the
paging-out/in code (never got off the drawing-board).
Some of the things I wanted to;
1) Reduce the time to find a candidate page, via swap_out() (it does
quite a bit of work, with no guarrantee the it finishes by
free a page).
2) If a named-page (ie. page associated with an inode) is shared among
processes, being able to quickly identify the pte's which ref the
page so that swap_out() has a better chance of actually freeing a
physical page.
3) Being able to swap out shared anonymous pages (such as the stack
after a fork - doesn't the line "if (page_map->count != 1)", in
try_to_swap_out() prevent this for anonymous pages?).
4) Being able to free pages that are contiguous in physical memory
and/or (for named pages) that are contiguous in the filesystem (so
that read-ahead can bring them in when they are probably needed -
ref your second wish).
5) Being able to free a page(s) of a particular type, eg. DMA, a certain
colour (for L2 cache colouring), or local (incase Linux every
supports the NUMA architecture :).
Add to the above better page ageing (the Linux design works pretty well,
but I think it can be improved upon), and you have a v. complicated
memory sub-system - which I don't have the time or experience to
undertake. If anyone is interested in a joint project of
trying to re-working the sub-system, I'd be happy to hear from you.
Regards,
markhe