[lkml]   [2001]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Break 2.4 VM in five easy steps
Andrew Morton <> 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.


> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:54    [W:1.088 / U:1.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site