Possible evidence of performance regression for 8.1-S (vs. 7.1)

[David Wolfskill]

On Tue, Oct 26, 2010 at 10:34:08AM -0400, Mike Tancsa wrote:
> At 07:29 AM 10/26/2010, David Wolfskill wrote:
> 
> >OK -- but we were using the default scheduler in each case.  The basic
> >point I'm making here is the apparent performance regression for
> >similarly-configured systems under 7.1 vs. 8.1.
> 
> 
> ULE is the default in 7 as well.

That was my recollection, yes.

> Perhaps remove some of the kernel options not in 7, that are in
> 8 by default?

I'll look at that while I run some NFS-specific tests per ivoras@'s
suggestion.

> What is the disk subsystem ? just ata ?

Errr... no.  :-}

ciss0: <HP Smart Array P410> port 0xd800-0xd8ff mem 0xfb800000-0xfbbfffff,0xfb7f
f000-0xfb7fffff irq 30 at device 0.0 on pci6
ciss0: PERFORMANT Transport
ciss0: [ITHREAD]
...
da0 at ciss0 bus 0 scbus0 target 0 lun 0
da0: <COMPAQ RAID 1(1VOLUME OK> Fixed Direct Access SCSI-5 device 
da0: 135.168MB/s transfers
da0: Command Queueing enabled
da0: 429215MB (879032432 512 byte sectors: 255H 32S/T 65535C)
da1 at ciss0 bus 0 scbus0 target 1 lun 0
da1: <COMPAQ RAID 0  VOLUME OK> Fixed Direct Access SCSI-5 device 
da1: 135.168MB/s transfers
da1: Command Queueing enabled
da1: 1716860MB (3516129392 512 byte sectors: 255H 32S/T 65535C)
da2 at ciss0 bus 0 scbus0 target 2 lun 0
da2: <COMPAQ RAID 0  VOLUME OK> Fixed Direct Access SCSI-5 device 
da2: 135.168MB/s transfers
da2: Command Queueing enabled
da2: 1716860MB (3516129392 512 byte sectors: 255H 32S/T 65535C)
da3 at ciss0 bus 0 scbus0 target 3 lun 0
da3: <COMPAQ RAID 0  VOLUME OK> Fixed Direct Access SCSI-5 device 
da3: 135.168MB/s transfers
da3: Command Queueing enabled
da3: 858430MB (1758064752 512 byte sectors: 255H 32S/T 65535C)

The logical drive where the activity is taking place is /dev/da1,
which is a 4-spindle RAID 0 group of 15Krpm SAS drives.

CPU is:

CPU: Intel(R) Xeon(R) CPU           E5540  @ 2.53GHz (2533.44-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x106a5  Family = 6  Model = 1a  Stepping = 5
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x9ce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT>
  AMD Features=0x28100000<NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  TSC: P-state invariant
...
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  2
 cpu2 (AP): APIC ID:  4
 cpu3 (AP): APIC ID:  6
 cpu4 (AP): APIC ID: 16
 cpu5 (AP): APIC ID: 18
 cpu6 (AP): APIC ID: 20
 cpu7 (AP): APIC ID: 22

> They seem innocuous enough, but worth a try
> 
> options        HWPMC_HOOKS             # Necessary kernel hooks for hwpmc(4)
> options        MAC                     # TrustedBSD MAC Framework
> options        FLOWTABLE               # per-cpu routing cache
> ...

Well, MAC should probably stay, as we use the MAC kernel config for 7.1.


Also, to get the "patched" 7.1-R, the following steps suffice (in case
anyone is interested in attempting to reproduce the results):

* svn co release/7.1.0.
* svn merge -c186860 stable/7
* svn merge -c190970 stable/7
* svn merge -c203072 head
* svn merge -c209964 stable/7

Remember to use MAC as your kernel config.

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-performance/attachments/20101026/bca17ee2/attachment.pgp