Re: Break 2.4 VM in five easy steps

Derek Glidden (dglidden@illusionary.com)
Tue, 5 Jun 2001 23:19:08 -0400


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/