On Thu, 2 Aug 2001, Jeffrey W. Baker wrote:
>
>
> On Thu, 2 Aug 2001, Richard B. Johnson wrote:
>
> > Seriously, it doesn't do any good to state that something sucks. You
> > need to point out the specific problem that you are experiencing.
> > "going to la la land.." is not quite technical enough. In fact, you
> > imply that the machine is still alive because of "disk thrashing".
> > If, in fact, you are a member of the Association for Computing Machinery
> > (so am I), you should know all this. Playing Troll doesn't help.
> >
> > If you suspend (^Z) one of the huge tasks, does the thrashing stop?
> > When suspended, do you still have swap-file space?
> > Are you sure you have managed the user quotas so that the sum of
> > the user's demands for resources can't bring down the machine?
>
> Anyone having observed this mailing list over the last year knows the
> problem I'm a talking about. kswapd can get itself into a state where it
> consumes 100% CPU time for hours at a stretch. During this time, the
> machine is unusable. There is no way to kill or suspend a task because
> the shells aren't getting scheduled and they can't accept input. During
> this time, the disks aren't running of course. Leading up to this, the
> disks do run. Then when kswapd steps in, they stop, or the throughput
> falls to a trickle.
>
> Here's a nice trick to pull on any Linux 2.4 box. Allocate all of the RAM
> in the machine and keep it. Now, thrash the VM by e.g. find / -exec cat
> {} \; Watch what happens. The kernel will try to grow and grow the disk
> cache by swapping your process out to disk. But, there may not be enough
> room for your process and all the cache that the kernel wants, so the
> machine goes into this sort of soft-deadlock state where kswapd goes away
> for a lunch break.
Well I don't have any such problems here. I wrote this script
from your instructions. I don't know if you REALLY wanted all
the file content to go out to the screen, but I wrote it explicitly.
#!/bin/bash
#
#
SIZ=`head --lines 2 /proc/meminfo | grep Mem | cut -d' ' -f3`
cat >/tmp/try.c <<EOF
#include <stdio.h>
#include <unistd.h>
#include <malloc.h>
int main(void);
int main()
{
char *cp;
cp = malloc($SIZ);
memset(cp, 0x55, $SIZ);
pause();
return 0;
}
EOF
gcc -Wall -O2 -o /tmp/try /tmp/try.c
/tmp/try &
find / -exec cat {} \;
# end
Script started on Thu Aug 2 16:50:47 2001
# ps -laxw | grep pause
140 0 16 1 -1 -20 712 40 pause S < ? 0:00 (bdflush) te
0 0 7433 1 9 0 321056 137808 pause S 1 0:02 /tmp/try
0 0 7631 7626 19 0 844 240 R p0 0:00 grep pause
# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 328048640 326234112 1814528 0 4255744 173219840
Swap: 1069268992 189992960 879276032
MemTotal: 320360 kB
MemFree: 1772 kB
MemShared: 0 kB
Buffers: 4156 kB
Cached: 169160 kB
Active: 9616 kB
Inact_dirty: 36012 kB
Inact_clean: 127688 kB
Inact_target: 780 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 320360 kB
LowFree: 1772 kB
SwapTotal: 1044208 kB
SwapFree: 858668 kB
# exit
exit
Script done on Thu Aug 2 16:51:26 2001
As you can see, it was quite sucessful in writing to real-RAM-size
of virtual RAM, then swapping it out so other stuff could run.
You can also do:
for(;;)
memset(cp, 0x55, $SIZ);
... and have a very slow, but usable, system. This was from the
root account with no quotas.
Perhaps there are problems with buffers that I don't have because
I use SCSI disks for everything.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:24 EST