Andrew Morton <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
