> A problem with this is that normal paging-in is allowed to page other
> things out as well. But you can't have that when swap is about to
> be turned off. My guess is that swapoff functionality was perceived to
> be so seldom used that they didn't bother too much with scheduling
> or efficiency.
There is some truth in that. You aren't allowed to allocate new pages
in the swap space currently being removed however. The current swap
off code removes pages from the current swap space without breaking
any sharing between swap pages. Depending on your load this may be
important. Fixing swapoff to be more efficient while at the same time
keeping sharing between pages is tricky. That under loads that are
easy to trigger in 2.4 swapoff never sleeps is a big bug.
> I don't have the same problem myself though. Shutting down with
> 30M or so in swap never take unusual time on 2.4.x kernels here,
> with a 300MHz processor. I did a test while typing this letter,
> almost filling the 96M swap partition with 88M. swapoff
> took 1 minute at 100% cpu. This is long, but the machine was responsive
> most of that time. I.e. no worse than during a kernel compile.
> The machine froze 10 seconds or so at the end of the minute, I can
> imagine that biting with bigger swap.
O.k. so at some point you actually wait for I/O and other process get
a chance to run. On the larger machines we never wait for I/O and
thus never schedule at all.
The problem is now understood. Now we just need to fix it.
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/