Messages in this thread | | | From | Derek Glidden <> | Date | Tue, 5 Jun 2001 23:19:08 -0400 | Subject | Re: Break 2.4 VM in five easy steps |
| |
On Wed, Jun 06, 2001 at 12:16:30PM +1000, Andrew Morton wrote: > "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.
I disagree with the terminology you're using. It *is* worse in 2.4, period. If it only *appears* worse, then if I encounter a situation where a 2.2 box has utilized as much swap as a 2.4 box, I should see the same results. Yet this happens not to be the case.
A 2.2 box that's a hundred or more megs into swap, even when that swap space is "actual programs" rather than just mysteriously allocated swap (as with 2.4), it only takes the time to page all that off disk back into RAM, making the machine a little sluggish while it's happening and definitely not making the machine entirely unresponsive.
On the other hand, a 2.4 box that's a hundred or more megs into swap, even when there's nothing actually running to take up that swap space, i.e. it's just "mysteriously allocated for some reason" swap, will take several minutes, while the CPU is pegged, the drive is inactive, and the entire machine is completely unresponsive to anything - for all appearances locked up tight.
I have been unable to make a box running the 2.2 kernel behave the same way as 2.4 does, even if I put the 2.2 kernel under severe memory pressure and the 2.4 kernel is entirely idle with no tasks but the most basic system processes running.
So from my perspective, which really is a real-world perspective because I can cause this same behaviour during normal day-to-day desktop operation of my machine, the behaviour of 2.4 *is* different from the behaviour of 2.2 when it comes to memory management.
> > 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: > [...] > It's interesting that you've found a case where this > actually has an operational impact.
I can't tell if this is humour or not. I hope it is, because I can sure show you actual operational impact of this mis-behaviour all day long. :)
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - 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/
| |