Re: Swapping in 2.1.103?

Re: Swapping in 2.1.103?

[Rik van Riel]

[CC:d to linux-mm because of the TODO list and because Jim
 is generally suggesting to team up with us :) ]

On Thu, 21 May 1998, Jim Wilcoxson wrote:

> Hi Rik - I've been running Linux a few years now, but have only been on the
> mailing list a few days and am not familiar with Linux internals.  I think
> it's a great OS though, and would love to contribute.  I'd like to spend a
> few days reviewing the current file system/paging algorithms and doing some
> tests on my machine to make sure I understand before spouting off
> suggestions.  Is it reasonable to review to 2.0.33 code, or should I look
> at the 2.1.x stuff?

It depends. If you're mainly looking at the 'high-level'
pageout daemon and the mmap() stuff, 2.0.33 will be fine.
The low-level stuff (swapcache, locking, etc) have changed
considerable, and are much more 'interesting' in 2.1.x...

Also, the 2.1 kernel is more interesting because any changes
you make have a larger probability of being saved for
future generations :)

We have several things in the TODO list currently:
- reverse pte lookup  -- being done by sct and blah
- true swapping -- I have the designs next to me, NYI
- out-of-memory process killing -- you can download the bulk
				of the code from my homepage
- swapin clustering -- I have some random thoughts, but NYI
- a zone allocator, instead of the current buddy allocator
		-- I have the design, but NYI
- some minor kswapd fixes -- we know what to fix, just not
			how, and it's minor anyway...
- prepaging -- I have some ideas on how to do this, no
			solid design and NYI

In short, the Linux VM system is nice & fast, but
far from perfect. I think there are still several
man-years to be invested and we can always welcome
a new person to the scene.

There's also a mailing list:
linux-mm@blah.kvack.org    (majordomo@blah.kvack.org)

Rik.
+-------------------------------------------+--------------------------+
| Linux: - LinuxHQ MM-patches page          | Scouting       webmaster |
|        - kswapd ask-him & complain-to guy | Vries    cubscout leader |
|     http://www.phys.uu.nl/~riel/          | <H.H.vanRiel@phys.uu.nl> |
+-------------------------------------------+--------------------------+

Re: Swapping in 2.1.103?

[Eric W. Biederman]

>>>>> "RR" == Rik van Riel <H.H.vanRiel@phys.uu.nl> writes:

RR> [CC:d to linux-mm because of the TODO list and because Jim
RR>  is generally suggesting to team up with us :) ]

Well here are my 2 cents for the TODO list.

RR> We have several things in the TODO list currently:
RR> - reverse pte lookup  -- being done by sct and blah
RR> - true swapping -- I have the designs next to me, NYI
RR> - out-of-memory process killing -- you can download the bulk
RR> 				of the code from my homepage
RR> - swapin clustering -- I have some random thoughts, but NYI
RR> - a zone allocator, instead of the current buddy allocator
RR> 		-- I have the design, but NYI
RR> - some minor kswapd fixes -- we know what to fix, just not
RR> 			how, and it's minor anyway...
RR> - prepaging -- I have some ideas on how to do this, no
RR> 			solid design and NYI
      I think reverse pte lookup and a pgflush daemon (see below)
      could handle most of this.  We would still need kswapd for page
      aging,  and the issue of when to start prepaging.... 

    - foreign swap allocation -- cleaning up the interface to swap
        pages so my shmfs filesystem, SYSV shared memory, and someday
        others, can handle swapoff and so rw_page_cache isn't so
        possesive.  In progress.
    - dirty page cache pages 
	-- Adding code so we can write things directly out of the page
           cache.  This should help compressed filesystems, and
           network filesystems for whom the block cache doesn't work.

           I have written shmfs a totally nonsynchronous filesystem
           that resides in swap, and uses my test code.  Currently I
           have some resource allocations issues to deal with for
           swap, and a pgflush kernel daemon to write (which should
           also be able to handle prepaging...), to write out dirty
           data in a timely manner.

Eric