Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Jens Axboe wrote: On Thu, Apr 19 2007, Valerie Clement wrote: Jens Axboe wrote: On Thu, Apr 19 2007, Valerie Clement wrote: Jens Axboe wrote: Please tell me how you are running ffsb, and also please include a dmessg from a booted system. Hi, our mails crossed! please see my response to Andrew. You could reproduce the problem with dd command as suggested, it's more easy. I'm sending you the dmesg info. For my tests I used the scsci sdc device. Thanks, it does. Can you try one thing for me? If you run the test on sdc, try doing: # echo 64 > /sys/block/sdc/queue/iosched/quantum and repeat the test. OK, that's done. With the change of quantum, the throughput scores are now a little bit better in 2.6.21 than in 2.6.20. Wonderful, now try the patch I sent in the next mail and repeat the test. That's done too. Now I've got the same results in 2.6.21 as in 2.6.20. Thanks, Valérie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
On Thu, Apr 19 2007, Valerie Clement wrote: > Jens Axboe wrote: > >On Thu, Apr 19 2007, Valerie Clement wrote: > >>Jens Axboe wrote: > >>>Please tell me how you are running ffsb, and also please include a > >>>dmessg from a booted system. > >>> > >>Hi, > >>our mails crossed! please see my response to Andrew. > >>You could reproduce the problem with dd command as suggested, it's more > >>easy. > >>I'm sending you the dmesg info. For my tests I used the scsci sdc device. > > > >Thanks, it does. Can you try one thing for me? If you run the test on > >sdc, try doing: > > > ># echo 64 > /sys/block/sdc/queue/iosched/quantum > > > >and repeat the test. > > > > OK, that's done. > > With the change of quantum, the throughput scores are now a little bit > better in 2.6.21 than in 2.6.20. Wonderful, now try the patch I sent in the next mail and repeat the test. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Jens Axboe wrote: On Thu, Apr 19 2007, Valerie Clement wrote: Jens Axboe wrote: Please tell me how you are running ffsb, and also please include a dmessg from a booted system. Hi, our mails crossed! please see my response to Andrew. You could reproduce the problem with dd command as suggested, it's more easy. I'm sending you the dmesg info. For my tests I used the scsci sdc device. Thanks, it does. Can you try one thing for me? If you run the test on sdc, try doing: # echo 64 > /sys/block/sdc/queue/iosched/quantum and repeat the test. OK, that's done. With the change of quantum, the throughput scores are now a little bit better in 2.6.21 than in 2.6.20. Valérie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
On Thu, Apr 19 2007, Jens Axboe wrote:
> On Thu, Apr 19 2007, Valerie Clement wrote:
> > Jens Axboe wrote:
> > >Please tell me how you are running ffsb, and also please include a
> > >dmessg from a booted system.
> > >
> > Hi,
> > our mails crossed! please see my response to Andrew.
> > You could reproduce the problem with dd command as suggested, it's more
> > easy.
> > I'm sending you the dmesg info. For my tests I used the scsci sdc device.
>
> Thanks, it does. Can you try one thing for me? If you run the test on
> sdc, try doing:
>
> # echo 64 > /sys/block/sdc/queue/iosched/quantum
>
> and repeat the test.
And, then try this one as well (and don't tweak quantum for that
kernel):
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index b6491c0..9e37971 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -986,9 +986,9 @@ __cfq_dispatch_requests(struct cfq_data *cfqd, struct
cfq_queue *cfqq,
* expire an async queue immediately if it has used up its slice. idle
* queue always expire after 1 dispatch round.
*/
- if ((!cfq_cfqq_sync(cfqq) &&
+ if (cfqd->busy_queues > 1 && ((!cfq_cfqq_sync(cfqq) &&
cfqd->dispatch_slice >= cfq_prio_to_maxrq(cfqd, cfqq)) ||
- cfq_class_idle(cfqq)) {
+ cfq_class_idle(cfqq))) {
cfqq->slice_end = jiffies + 1;
cfq_slice_expired(cfqd, 0, 0);
}
@@ -1051,19 +1051,21 @@ cfq_dispatch_requests(request_queue_t *q, int force)
while ((cfqq = cfq_select_queue(cfqd)) != NULL) {
int max_dispatch;
- /*
-* Don't repeat dispatch from the previous queue.
-*/
- if (prev_cfqq == cfqq)
- break;
+ if (cfqd->busy_queues > 1) {
+ /*
+* Don't repeat dispatch from the previous queue.
+*/
+ if (prev_cfqq == cfqq)
+ break;
- /*
-* So we have dispatched before in this round, if the
-* next queue has idling enabled (must be sync), don't
-* allow it service until the previous have continued.
-*/
- if (cfqd->rq_in_driver && cfq_cfqq_idle_window(cfqq))
- break;
+ /*
+* So we have dispatched before in this round, if the
+* next queue has idling enabled (must be sync), don't
+* allow it service until the previous have continued.
+*/
+ if (cfqd->rq_in_driver && cfq_cfqq_idle_window(cfqq))
+ break;
+ }
cfq_clear_cfqq_must_dispatch(cfqq);
cfq_clear_cfqq_wait_request(cfqq);
@@ -1370,7 +1372,9 @@ retry:
atomic_set(>ref, 0);
cfqq->cfqd = cfqd;
- cfq_mark_cfqq_idle_window(cfqq);
+ if (key != CFQ_KEY_ASYNC)
+ cfq_mark_cfqq_idle_window(cfqq);
+
cfq_mark_cfqq_prio_changed(cfqq);
cfq_mark_cfqq_queue_new(cfqq);
cfq_init_prio_data(cfqq);
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
On Thu, Apr 19 2007, Valerie Clement wrote: > Jens Axboe wrote: > >Please tell me how you are running ffsb, and also please include a > >dmessg from a booted system. > > > Hi, > our mails crossed! please see my response to Andrew. > You could reproduce the problem with dd command as suggested, it's more > easy. > I'm sending you the dmesg info. For my tests I used the scsci sdc device. Thanks, it does. Can you try one thing for me? If you run the test on sdc, try doing: # echo 64 > /sys/block/sdc/queue/iosched/quantum and repeat the test. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Jens Axboe wrote: Please tell me how you are running ffsb, and also please include a dmessg from a booted system. Hi, our mails crossed! please see my response to Andrew. You could reproduce the problem with dd command as suggested, it's more easy. I'm sending you the dmesg info. For my tests I used the scsci sdc device. Hope this help, Valérie Linux version 2.6.21-rc7 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Wed Apr 18 11:39:56 CEST 2007 Command line: console=ttyS0,57600n8 BIOS-provided physical RAM map: BIOS-e820: - 0009b400 (usable) BIOS-e820: 0009b400 - 000a (reserved) BIOS-e820: 000cc000 - 000d8000 (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 7ff7 (usable) BIOS-e820: 7ff7 - 7ff7b000 (ACPI data) BIOS-e820: 7ff7b000 - 7ff8 (ACPI NVS) BIOS-e820: 7ff8 - 8000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff80 - ffc0 (reserved) BIOS-e820: fc00 - 0001 (reserved) Entering add_active_range(0, 0, 155) 0 entries of 3200 used Entering add_active_range(0, 256, 524144) 1 entries of 3200 used end_pfn_map = 1047552 DMI 2.3 present. ACPI: RSDP 000F6940, 0014 (r0 PTLTD ) ACPI: RSDT 7FF766C5, 0034 (r1 PTLTDRSDT604 LTP0) ACPI: FACP 7FF7AE94, 0074 (r1 INTEL LINDHRST 604 PTL 3) ACPI: DSDT 7FF766F9, 479B (r1 Intel LINDHRST 604 MSFT 10E) ACPI: FACS 7FF7BFC0, 0040 ACPI: MCFG 7FF7AF08, 0040 (r1 PTLTD MCFG604 LTP0) ACPI: APIC 7FF7AF48, 0090 (r1 PTLTD APIC604 LTP0) ACPI: BOOT 7FF7AFD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) No NUMA configuration found Faking a node at -7ff7 Entering add_active_range(0, 0, 155) 0 entries of 3200 used Entering add_active_range(0, 256, 524144) 1 entries of 3200 used Bootmem setup node 0 -7ff7 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 155 0: 256 -> 524144 On node 0 totalpages: 524043 DMA zone: 56 pages used for memmap DMA zone: 1829 pages reserved DMA zone: 2110 pages, LIFO batch:0 DMA32 zone: 7110 pages used for memmap DMA32 zone: 512938 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled) Processor #6 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled) Processor #7 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: IOAPIC (id[0x03] address[0xfec1] gsi_base[24]) IOAPIC[1]: apic_id 3, address 0xfec1, GSI 24-47 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to physical flat Using ACPI (MADT) for SMP configuration information Nosave address range: 0009b000 - 0009c000 Nosave address range: 0009c000 - 000a Nosave address range: 000a - 000cc000 Nosave address range: 000cc000 - 000d8000 Nosave address range: 000d8000 - 000e Nosave address range: 000e - 0010 Allocating PCI resources starting at 8800 (gap: 8000:6000) SMP: Allowing 4 CPUs, 0 hotplug CPUs PERCPU: Allocating 37760 bytes of per cpu data Built 1 zonelists. Total pages: 515048 Kernel command line: console=ttyS0,57600n8 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) time.c: Detected 2793.059 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Checking aperture... Memory: 2056596k/2096576k available (3816k kernel code, 39576k reserved, 2214k data, 336k init) Calibrating delay using timer specific routine.. 5590.47 BogoMIPS (lpj=11180941) Mount-cache hash table entries: 256 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU 0/0 -> Node 0 using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Andrew Morton wrote: It could be due to I/O scheduler changes. Which one are you using? CFQ? Or it could be that there has been some changed behaviour at the VFS/pagecache layer: the VFS might be submitting little hunks of lots of files, rather than large hunks of few files. Or it could be a block-layer thing: perhaps some driver change has caused us to be placing less data into the queue. Which device driver is that machine using? Being a simple soul, the first thing I'll try when I get near a test box will be for i in $(seq 1 16) do time dd if=/dev/zero of=$i bs=1M count=1024 & done I tried first the test with dd, the results are similar to those of FFSB tests, about 15 percent of degradation between 2.6.20.7 and 2.6.21-rc7. I'm using the CFQ I/O scheduler. I changed it to the "deadline" one and I don't have any more the problem, I've got similar throughput values with 2.6.20.7 and 2.6.21-rc7 kernels. So can we conclude that it's due to the CFQ scheduler? I also checked the device driver used, the revision number is the same in 2.6.20 and 2.6.21. Valérie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
On Wed, Apr 18 2007, Valerie Clement wrote: > > Running benchmark tests (FFSB) on an ext4 filesystem, I noticed a > performance degradation (about 15-20 percent) in sequential write tests > between 2.6.19-rc6 and 2.6.21-rc4 kernels. > > I ran the same tests on ext3 and XFS filesystems and I saw the same > performance difference between the two kernel versions for these two > filesystems. > > I have also reproduced it between 2.6.20.7 and 2.6.21-rc7. > The FFSB tests run 16 threads, each creating 1GB files. The tests were > done on the same x86_64 system, with the same kernel configuration and > on the same scsi device. Below are the throughput values given by FFSB. > > kernel XFSext3 > -- > 2.6.20.748 MB/sec 44 MB/sec > > 2.6.21-rc7 38 MB/sec 37 MB/sec > > Did anyone else run across the problem? > Is there a known issue? Please tell me how you are running ffsb, and also please include a dmessg from a booted system. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
On Wed, Apr 18 2007, Valerie Clement wrote: Running benchmark tests (FFSB) on an ext4 filesystem, I noticed a performance degradation (about 15-20 percent) in sequential write tests between 2.6.19-rc6 and 2.6.21-rc4 kernels. I ran the same tests on ext3 and XFS filesystems and I saw the same performance difference between the two kernel versions for these two filesystems. I have also reproduced it between 2.6.20.7 and 2.6.21-rc7. The FFSB tests run 16 threads, each creating 1GB files. The tests were done on the same x86_64 system, with the same kernel configuration and on the same scsi device. Below are the throughput values given by FFSB. kernel XFSext3 -- 2.6.20.748 MB/sec 44 MB/sec 2.6.21-rc7 38 MB/sec 37 MB/sec Did anyone else run across the problem? Is there a known issue? Please tell me how you are running ffsb, and also please include a dmessg from a booted system. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Andrew Morton wrote: It could be due to I/O scheduler changes. Which one are you using? CFQ? Or it could be that there has been some changed behaviour at the VFS/pagecache layer: the VFS might be submitting little hunks of lots of files, rather than large hunks of few files. Or it could be a block-layer thing: perhaps some driver change has caused us to be placing less data into the queue. Which device driver is that machine using? Being a simple soul, the first thing I'll try when I get near a test box will be for i in $(seq 1 16) do time dd if=/dev/zero of=$i bs=1M count=1024 done I tried first the test with dd, the results are similar to those of FFSB tests, about 15 percent of degradation between 2.6.20.7 and 2.6.21-rc7. I'm using the CFQ I/O scheduler. I changed it to the deadline one and I don't have any more the problem, I've got similar throughput values with 2.6.20.7 and 2.6.21-rc7 kernels. So can we conclude that it's due to the CFQ scheduler? I also checked the device driver used, the revision number is the same in 2.6.20 and 2.6.21. Valérie - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Jens Axboe wrote: Please tell me how you are running ffsb, and also please include a dmessg from a booted system. Hi, our mails crossed! please see my response to Andrew. You could reproduce the problem with dd command as suggested, it's more easy. I'm sending you the dmesg info. For my tests I used the scsci sdc device. Hope this help, Valérie Linux version 2.6.21-rc7 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 SMP Wed Apr 18 11:39:56 CEST 2007 Command line: console=ttyS0,57600n8 BIOS-provided physical RAM map: BIOS-e820: - 0009b400 (usable) BIOS-e820: 0009b400 - 000a (reserved) BIOS-e820: 000cc000 - 000d8000 (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 7ff7 (usable) BIOS-e820: 7ff7 - 7ff7b000 (ACPI data) BIOS-e820: 7ff7b000 - 7ff8 (ACPI NVS) BIOS-e820: 7ff8 - 8000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff80 - ffc0 (reserved) BIOS-e820: fc00 - 0001 (reserved) Entering add_active_range(0, 0, 155) 0 entries of 3200 used Entering add_active_range(0, 256, 524144) 1 entries of 3200 used end_pfn_map = 1047552 DMI 2.3 present. ACPI: RSDP 000F6940, 0014 (r0 PTLTD ) ACPI: RSDT 7FF766C5, 0034 (r1 PTLTDRSDT604 LTP0) ACPI: FACP 7FF7AE94, 0074 (r1 INTEL LINDHRST 604 PTL 3) ACPI: DSDT 7FF766F9, 479B (r1 Intel LINDHRST 604 MSFT 10E) ACPI: FACS 7FF7BFC0, 0040 ACPI: MCFG 7FF7AF08, 0040 (r1 PTLTD MCFG604 LTP0) ACPI: APIC 7FF7AF48, 0090 (r1 PTLTD APIC604 LTP0) ACPI: BOOT 7FF7AFD8, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) No NUMA configuration found Faking a node at -7ff7 Entering add_active_range(0, 0, 155) 0 entries of 3200 used Entering add_active_range(0, 256, 524144) 1 entries of 3200 used Bootmem setup node 0 -7ff7 Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 155 0: 256 - 524144 On node 0 totalpages: 524043 DMA zone: 56 pages used for memmap DMA zone: 1829 pages reserved DMA zone: 2110 pages, LIFO batch:0 DMA32 zone: 7110 pages used for memmap DMA32 zone: 512938 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x06] enabled) Processor #6 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x07] enabled) Processor #7 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: IOAPIC (id[0x03] address[0xfec1] gsi_base[24]) IOAPIC[1]: apic_id 3, address 0xfec1, GSI 24-47 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to physical flat Using ACPI (MADT) for SMP configuration information Nosave address range: 0009b000 - 0009c000 Nosave address range: 0009c000 - 000a Nosave address range: 000a - 000cc000 Nosave address range: 000cc000 - 000d8000 Nosave address range: 000d8000 - 000e Nosave address range: 000e - 0010 Allocating PCI resources starting at 8800 (gap: 8000:6000) SMP: Allowing 4 CPUs, 0 hotplug CPUs PERCPU: Allocating 37760 bytes of per cpu data Built 1 zonelists. Total pages: 515048 Kernel command line: console=ttyS0,57600n8 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) time.c: Detected 2793.059 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Checking aperture... Memory: 2056596k/2096576k available (3816k kernel code, 39576k reserved, 2214k data, 336k init) Calibrating delay using timer specific routine.. 5590.47 BogoMIPS (lpj=11180941) Mount-cache hash table entries: 256 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 1024K CPU 0/0 - Node 0 using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
On Thu, Apr 19 2007, Valerie Clement wrote: Jens Axboe wrote: Please tell me how you are running ffsb, and also please include a dmessg from a booted system. Hi, our mails crossed! please see my response to Andrew. You could reproduce the problem with dd command as suggested, it's more easy. I'm sending you the dmesg info. For my tests I used the scsci sdc device. Thanks, it does. Can you try one thing for me? If you run the test on sdc, try doing: # echo 64 /sys/block/sdc/queue/iosched/quantum and repeat the test. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
On Thu, Apr 19 2007, Jens Axboe wrote:
On Thu, Apr 19 2007, Valerie Clement wrote:
Jens Axboe wrote:
Please tell me how you are running ffsb, and also please include a
dmessg from a booted system.
Hi,
our mails crossed! please see my response to Andrew.
You could reproduce the problem with dd command as suggested, it's more
easy.
I'm sending you the dmesg info. For my tests I used the scsci sdc device.
Thanks, it does. Can you try one thing for me? If you run the test on
sdc, try doing:
# echo 64 /sys/block/sdc/queue/iosched/quantum
and repeat the test.
And, then try this one as well (and don't tweak quantum for that
kernel):
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index b6491c0..9e37971 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -986,9 +986,9 @@ __cfq_dispatch_requests(struct cfq_data *cfqd, struct
cfq_queue *cfqq,
* expire an async queue immediately if it has used up its slice. idle
* queue always expire after 1 dispatch round.
*/
- if ((!cfq_cfqq_sync(cfqq)
+ if (cfqd-busy_queues 1 ((!cfq_cfqq_sync(cfqq)
cfqd-dispatch_slice = cfq_prio_to_maxrq(cfqd, cfqq)) ||
- cfq_class_idle(cfqq)) {
+ cfq_class_idle(cfqq))) {
cfqq-slice_end = jiffies + 1;
cfq_slice_expired(cfqd, 0, 0);
}
@@ -1051,19 +1051,21 @@ cfq_dispatch_requests(request_queue_t *q, int force)
while ((cfqq = cfq_select_queue(cfqd)) != NULL) {
int max_dispatch;
- /*
-* Don't repeat dispatch from the previous queue.
-*/
- if (prev_cfqq == cfqq)
- break;
+ if (cfqd-busy_queues 1) {
+ /*
+* Don't repeat dispatch from the previous queue.
+*/
+ if (prev_cfqq == cfqq)
+ break;
- /*
-* So we have dispatched before in this round, if the
-* next queue has idling enabled (must be sync), don't
-* allow it service until the previous have continued.
-*/
- if (cfqd-rq_in_driver cfq_cfqq_idle_window(cfqq))
- break;
+ /*
+* So we have dispatched before in this round, if the
+* next queue has idling enabled (must be sync), don't
+* allow it service until the previous have continued.
+*/
+ if (cfqd-rq_in_driver cfq_cfqq_idle_window(cfqq))
+ break;
+ }
cfq_clear_cfqq_must_dispatch(cfqq);
cfq_clear_cfqq_wait_request(cfqq);
@@ -1370,7 +1372,9 @@ retry:
atomic_set(cfqq-ref, 0);
cfqq-cfqd = cfqd;
- cfq_mark_cfqq_idle_window(cfqq);
+ if (key != CFQ_KEY_ASYNC)
+ cfq_mark_cfqq_idle_window(cfqq);
+
cfq_mark_cfqq_prio_changed(cfqq);
cfq_mark_cfqq_queue_new(cfqq);
cfq_init_prio_data(cfqq);
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Jens Axboe wrote: On Thu, Apr 19 2007, Valerie Clement wrote: Jens Axboe wrote: Please tell me how you are running ffsb, and also please include a dmessg from a booted system. Hi, our mails crossed! please see my response to Andrew. You could reproduce the problem with dd command as suggested, it's more easy. I'm sending you the dmesg info. For my tests I used the scsci sdc device. Thanks, it does. Can you try one thing for me? If you run the test on sdc, try doing: # echo 64 /sys/block/sdc/queue/iosched/quantum and repeat the test. OK, that's done. With the change of quantum, the throughput scores are now a little bit better in 2.6.21 than in 2.6.20. Valérie - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
On Thu, Apr 19 2007, Valerie Clement wrote: Jens Axboe wrote: On Thu, Apr 19 2007, Valerie Clement wrote: Jens Axboe wrote: Please tell me how you are running ffsb, and also please include a dmessg from a booted system. Hi, our mails crossed! please see my response to Andrew. You could reproduce the problem with dd command as suggested, it's more easy. I'm sending you the dmesg info. For my tests I used the scsci sdc device. Thanks, it does. Can you try one thing for me? If you run the test on sdc, try doing: # echo 64 /sys/block/sdc/queue/iosched/quantum and repeat the test. OK, that's done. With the change of quantum, the throughput scores are now a little bit better in 2.6.21 than in 2.6.20. Wonderful, now try the patch I sent in the next mail and repeat the test. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Jens Axboe wrote: On Thu, Apr 19 2007, Valerie Clement wrote: Jens Axboe wrote: On Thu, Apr 19 2007, Valerie Clement wrote: Jens Axboe wrote: Please tell me how you are running ffsb, and also please include a dmessg from a booted system. Hi, our mails crossed! please see my response to Andrew. You could reproduce the problem with dd command as suggested, it's more easy. I'm sending you the dmesg info. For my tests I used the scsci sdc device. Thanks, it does. Can you try one thing for me? If you run the test on sdc, try doing: # echo 64 /sys/block/sdc/queue/iosched/quantum and repeat the test. OK, that's done. With the change of quantum, the throughput scores are now a little bit better in 2.6.21 than in 2.6.20. Wonderful, now try the patch I sent in the next mail and repeat the test. That's done too. Now I've got the same results in 2.6.21 as in 2.6.20. Thanks, Valérie - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
> On Wed, 18 Apr 2007 15:54:00 +0200 Valerie Clement <[EMAIL PROTECTED]> wrote: > > Running benchmark tests (FFSB) on an ext4 filesystem, I noticed a > performance degradation (about 15-20 percent) in sequential write tests > between 2.6.19-rc6 and 2.6.21-rc4 kernels. > > I ran the same tests on ext3 and XFS filesystems and I saw the same > performance difference between the two kernel versions for these two > filesystems. > > I have also reproduced it between 2.6.20.7 and 2.6.21-rc7. > The FFSB tests run 16 threads, each creating 1GB files. The tests were > done on the same x86_64 system, with the same kernel configuration and > on the same scsi device. Below are the throughput values given by FFSB. > >kernel XFSext3 > -- > 2.6.20.748 MB/sec 44 MB/sec > > 2.6.21-rc7 38 MB/sec 37 MB/sec > > Did anyone else run across the problem? > Is there a known issue? > That's a new discovery, thanks. It could be due to I/O scheduler changes. Which one are you using? CFQ? Or it could be that there has been some changed behaviour at the VFS/pagecache layer: the VFS might be submitting little hunks of lots of files, rather than large hunks of few files. Or it could be a block-layer thing: perhaps some driver change has caused us to be placing less data into the queue. Which device driver is that machine using? Being a simple soul, the first thing I'll try when I get near a test box will be for i in $(seq 1 16) do time dd if=/dev/zero of=$i bs=1M count=1024 & done - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Running benchmark tests (FFSB) on an ext4 filesystem, I noticed a performance degradation (about 15-20 percent) in sequential write tests between 2.6.19-rc6 and 2.6.21-rc4 kernels. I ran the same tests on ext3 and XFS filesystems and I saw the same performance difference between the two kernel versions for these two filesystems. I have also reproduced it between 2.6.20.7 and 2.6.21-rc7. The FFSB tests run 16 threads, each creating 1GB files. The tests were done on the same x86_64 system, with the same kernel configuration and on the same scsi device. Below are the throughput values given by FFSB. kernel XFSext3 -- 2.6.20.748 MB/sec 44 MB/sec 2.6.21-rc7 38 MB/sec 37 MB/sec Did anyone else run across the problem? Is there a known issue? Valérie (in attachment, my kernel configuration file) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7 # Wed Apr 18 11:29:53 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set CONFIG_GENERIC_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_NODES_SHIFT=6 CONFIG_X86_64_ACPI_NUMA=y CONFIG_NUMA_EMU=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set CONFIG_DISCONTIGMEM_MANUAL=y # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_DISCONTIGMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_NEED_MULTIPLE_NODES=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_OUT_OF_LINE_PFN_TO_PAGE=y CONFIG_NR_CPUS=32 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 #
Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
Running benchmark tests (FFSB) on an ext4 filesystem, I noticed a performance degradation (about 15-20 percent) in sequential write tests between 2.6.19-rc6 and 2.6.21-rc4 kernels. I ran the same tests on ext3 and XFS filesystems and I saw the same performance difference between the two kernel versions for these two filesystems. I have also reproduced it between 2.6.20.7 and 2.6.21-rc7. The FFSB tests run 16 threads, each creating 1GB files. The tests were done on the same x86_64 system, with the same kernel configuration and on the same scsi device. Below are the throughput values given by FFSB. kernel XFSext3 -- 2.6.20.748 MB/sec 44 MB/sec 2.6.21-rc7 38 MB/sec 37 MB/sec Did anyone else run across the problem? Is there a known issue? Valérie (in attachment, my kernel configuration file) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7 # Wed Apr 18 11:29:53 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set CONFIG_GENERIC_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_NODES_SHIFT=6 CONFIG_X86_64_ACPI_NUMA=y CONFIG_NUMA_EMU=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set CONFIG_DISCONTIGMEM_MANUAL=y # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_DISCONTIGMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_NEED_MULTIPLE_NODES=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_OUT_OF_LINE_PFN_TO_PAGE=y CONFIG_NR_CPUS=32 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # CONFIG_REORDER is
Re: Performance degradation with FFSB between 2.6.20 and 2.6.21-rc7
On Wed, 18 Apr 2007 15:54:00 +0200 Valerie Clement [EMAIL PROTECTED] wrote: Running benchmark tests (FFSB) on an ext4 filesystem, I noticed a performance degradation (about 15-20 percent) in sequential write tests between 2.6.19-rc6 and 2.6.21-rc4 kernels. I ran the same tests on ext3 and XFS filesystems and I saw the same performance difference between the two kernel versions for these two filesystems. I have also reproduced it between 2.6.20.7 and 2.6.21-rc7. The FFSB tests run 16 threads, each creating 1GB files. The tests were done on the same x86_64 system, with the same kernel configuration and on the same scsi device. Below are the throughput values given by FFSB. kernel XFSext3 -- 2.6.20.748 MB/sec 44 MB/sec 2.6.21-rc7 38 MB/sec 37 MB/sec Did anyone else run across the problem? Is there a known issue? That's a new discovery, thanks. It could be due to I/O scheduler changes. Which one are you using? CFQ? Or it could be that there has been some changed behaviour at the VFS/pagecache layer: the VFS might be submitting little hunks of lots of files, rather than large hunks of few files. Or it could be a block-layer thing: perhaps some driver change has caused us to be placing less data into the queue. Which device driver is that machine using? Being a simple soul, the first thing I'll try when I get near a test box will be for i in $(seq 1 16) do time dd if=/dev/zero of=$i bs=1M count=1024 done - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
