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 da...@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.
pgpOeMo3vnryq.pgp
Description: PGP signature
