freebsd stable - Dec 2005 - Odd performance problems after upgrade from 4.11 to 6.0-Stable

I recently upgraded my last desktop system from 4.11-Stable to
6.0-Stable. I did an update to 5.3 then to RELENG_5,
RELENG_6_0_0_RELEASE and on to RELENG6_0.

This system has been updated regularly from the days of at least 4.1.
The hardware is a 1GHz PIII with an ICH2 chipset. 256 MB of memory. 

After the upgrade, the system performs poorly. Specifically, it seems to
be blocking on I/O. If I have a dump or bsdtar running, a CPU intensive
job produced minimal CPU utilization and little progress. The system is
70% or more idle all of the time. X is particularly sluggish. Many times
the system will simply appear to be locked up for seconds at a time like
all of the I/O is synchronous and the entire system is blocking on GIANT
until the disk write finishes. A level 0 dump of the system drive piped
through gzip and over the network took about 10 hours. Now it is 17
hours. My network link only ran at 3.4 Mbps (yes, that's bits, not
Bytes) over a 100 Mbps connection to the storage server. The rate was
much higher under 4.11.

My attempts to track down the source of the problem simply failed. I
have examined my kernel configuration and found nothing out of the
ordinary. In fact, the the configuration varies from GENERIC only in
devices (both added and deleted), dropping 486 and 586 CPU code and a
larger SC_HISTORY. I have nothing in sysctl.conf and only enable DMA on
my ATAPI devices in loader.conf. I have confirmed that the disks are
running ATA100.

Any suggestions on where to look? At this point I am baffled.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634

Kevin Oberman wrote:
> I recently upgraded my last desktop system from 4.11-Stable to
> 6.0-Stable. I did an update to 5.3 then to RELENG_5,
> RELENG_6_0_0_RELEASE and on to RELENG6_0.
> 
> This system has been updated regularly from the days of at least 4.1.
> The hardware is a 1GHz PIII with an ICH2 chipset. 256 MB of memory. 
> 
> After the upgrade, the system performs poorly. Specifically, it seems to
> be blocking on I/O. If I have a dump or bsdtar running, a CPU intensive
> job produced minimal CPU utilization and little progress. The system is
> 70% or more idle all of the time. X is particularly sluggish. Many times
> the system will simply appear to be locked up for seconds at a time like
> all of the I/O is synchronous and the entire system is blocking on GIANT
> until the disk write finishes. A level 0 dump of the system drive piped
> through gzip and over the network took about 10 hours. Now it is 17
> hours. My network link only ran at 3.4 Mbps (yes, that's bits, not
> Bytes) over a 100 Mbps connection to the storage server. The rate was
> much higher under 4.11.
> 
> My attempts to track down the source of the problem simply failed. I
> have examined my kernel configuration and found nothing out of the
> ordinary. In fact, the the configuration varies from GENERIC only in
> devices (both added and deleted), dropping 486 and 586 CPU code and a
> larger SC_HISTORY. I have nothing in sysctl.conf and only enable DMA on
> my ATAPI devices in loader.conf. I have confirmed that the disks are
> running ATA100.
> 
> Any suggestions on where to look? At this point I am baffled.
The bufdaemon is probably causing some of the Giant contention. 
However, what it is contending with is the real question.  Is
your network driver and stack running MPSAFE?  At least a 'dmesg'
dump is needed here.

Also, taking out CPU_I586 is usually a bad idea.  It offers no 
performance penalties (unlike CPU_I386 and maybe CPU_I486), but
enables things like optimized bcopy.

Scott

On Thu, 2005-Dec-15 12:53:59 -0000, Steven Hartland
wrote:
>Same here be nice to get a catagoric answer to this.
>
>   Steve
>----- Original Message ----- 
>From: "Randy Rowe" <rerowe@rerowe.com>
>>
>>I have multiple dual and quad Pentium Pro machines running 4.x that have
>>been
>>remarkably stable using the I686_CPU setting (kudos to the
developers!!).
>>So I add myself to the list of those that have been removing the
>>I586_CPU option.
UTSL: The i586 optimised routines were only ever enabled if the CPU
was identified as a 586.  And these routines have been disabled since
mid-2001.  See my mail in the "Odd performance problems..."  thread
for more details.

-- 
Peter Jeremy

> UTSL: The i586 optimised routines were only ever enabled if the CPU
> was identified as a 586.  And these routines have been disabled since
> mid-2001.  See my mail in the "Odd performance problems..." 
thread
> for more details.
Got some curiuous results when I tested this today by the way.
I have a twin processor PIII machine. Did a parallel compile on
it. The actuall wall clock time is faster when I add the 586
back in. *but* if you look at the user and system times, the
user time has dropped slightly, but the system tme has gone up
a lot. So its doing more work, but with a slghtly greater amount
of parallelism allow it to finish faster in real time.

Can anyone explain that ????

-pete,.