We are seeing issues with a single tar of a large number files on a 6600
ruinging performance.

This problem appears to be the same as bugzilla 79257.

Here is the script that exposes the problem:

----------------------
#!/bin/bash2
  TEST_DIR=/tmp
# Tar's and Gzip's the linux kernel source 
  cd /usr/src
  tar cvf /$TEST_DIR/linux.tar linux-2.4/*
  gzip -f /$TEST_DIR/linux.tar
  SOURCE_FILE=$TEST_DIR/linux.tar.gz
cd $TEST_DIR
# Remove any possible left over directories from a 
rm -fr linux-2.4 linux.orig linux.pass.*
# Unpack the one copy of the source tree that we will be comparing against
tar -xzf $SOURCE_FILE
mv /tmp/linux-2.4 linux.orig
COUNT=80
j=0
  while [ "$j" -lt "$COUNT" ]; do
    tar -xzf $SOURCE_FILE
    echo "Loop $j out of $COUNT"
    echo "Extracting Source File to $TEST_DIR/linux.pass.$j"
    mv linux-2.4 linux.pass.$j
    j=`expr $j + 1`
  done
# Clean up
rm -fr linux-2.4 linux.orig linux.pass.*
----------------------


The system has 12GB and 4 Processors with HT on.  It will lock up under the
2.4.18-14bigmem kernel.  If you run with only 1 Processors with HT on it will
not lock up but will degrade performance.  If you run with 9GB or less and 4
Processors it will not lock up.

When performance degrades LowFree in /proc/meminfo is bellow 9MB.


According to the Bugzilla the latest kernel still has a performance hit but does
not lockup.  Will regress with newer errata kernel.

Are there any tests that can be tried to assist Red Hat with problem resolution?

----------
Action by: rhentosh
Issue Registered
----------
Action by: ltroan
Escalated to Bugzilla

ISSUE TRACKER 15164, opened as sev 2 against 8.0
(will correct bugzilla - not beta) 
PER ABOVE MAY BE DUP OF bugzilla 79257.