Re: Break 2.4 VM in five easy steps

[ebiederm@xmission.com (Eric W. Biederman)]

Andrew Morton <andrewm@uow.edu.au> writes:

> "Jeffrey W. Baker" wrote:
> > 
> > Because the 2.4 VM is so broken, and
> > because my machines are frequently deeply swapped,
> 
> The swapoff algorithms in 2.2 and 2.4 are basically identical.
> The problem *appears* worse in 2.4 because it uses lots
> more swap.

And 2.4 does delayed swap deallocation.  We don't appear to optimize
the case where a page is only used by the swap cache.  That should
be able to save some cpu overhead if nothing else.

And I do know that in the early 2.2 timeframe, swapoff was used
to generate an artifically high VM load, for testing the VM.  It looks
like that testing procedure has been abandoned :)

> > they can sometimes take over 30 minutes to shutdown.
> 
> Yes. The sys_swapoff() system call can take many minutes
> of CPU time.  It basically does:
> 
> 	for (each page in swap device) {
> 		for (each process) {
> 			for (each page used by this process)
> 				stuff
> 
> It's interesting that you've found a case where this
> actually has an operational impact.

Agreed.
 
> Haven't looked at it closely, but I think the algorithm
> could become something like:
> 
> 	for (each process) {
> 		for (each page in this process) {
> 			if (page is on target swap device)
> 				get_it_off()
> 		}
> 	}
> 
> 	for (each page in swap device) {
> 		if (it is busy)
> 			complain()
> 	}

You would need to handle the shared memory case as well.
But otherwise this looks sound.  I would suggest going
through page->address_space->i_mmap_shared to find all of the
potential mappings but the swapper address space is used by all
processes that have pages in swap.

> That's 10^4 to 10^6 times faster.

It looks like it could be.  The bottleneck should be diskio, if it
is not we have a noticeable inefficient algorithm.

Eric