| Subject | Re: Break 2.4 VM in five easy steps | From | (Eric W. Biederman) | Date | 06 Jun 2001 07:32:34 -0600 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|