2.6.23 performance regression
Hi, sorry if this is a faq but reading http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf (slides 17, 18) looks like 2.6.23 is having a performance regression on MySQL and PostgreSQL benchmarks. Has anyone investigated these? -- Lorenzo - 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/
2.6.23 performance regression
Hi, sorry if this is a faq but reading http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf (slides 17, 18) looks like 2.6.23 is having a performance regression on MySQL and PostgreSQL benchmarks. Has anyone investigated these? -- Lorenzo - 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: SMP performance degradation with sysbench
On Tue, 2007-02-27 at 20:05 +0100, Lorenzo Allegrucci wrote: > On Tue, 2007-02-27 at 09:02 -0500, Rik van Riel wrote: > > That still doesn't fix the potential Linux problem that this > > benchmark identified. > > > > To clarify: I don't care as much about MySQL performance as > > I care about identifying and fixing this potential bug in > > Linux. > > Here http://people.freebsd.org/~kris/scaling/mysql.html Kris Kennaway > talks about a patch for FreeBSD 7 which addresses poor scalability > of file descriptor locking and that it's responsible for almost all > of the performance and scaling improvements. How does Linux scale with many threads contending for file descriptor lock? Has anyone tried to run the test with oprofile? - 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: SMP performance degradation with sysbench
On Tue, 2007-02-27 at 20:05 +0100, Lorenzo Allegrucci wrote: On Tue, 2007-02-27 at 09:02 -0500, Rik van Riel wrote: That still doesn't fix the potential Linux problem that this benchmark identified. To clarify: I don't care as much about MySQL performance as I care about identifying and fixing this potential bug in Linux. Here http://people.freebsd.org/~kris/scaling/mysql.html Kris Kennaway talks about a patch for FreeBSD 7 which addresses poor scalability of file descriptor locking and that it's responsible for almost all of the performance and scaling improvements. How does Linux scale with many threads contending for file descriptor lock? Has anyone tried to run the test with oprofile? - 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: SMP performance degradation with sysbench
On Tue, 2007-02-27 at 09:02 -0500, Rik van Riel wrote: > J.A. Magallón wrote: > > On Mon, 26 Feb 2007 23:31:29 -0500, Rik van Riel <[EMAIL PROTECTED]> wrote: > > > >> Hiro Yoshioka wrote: > > >>> Another question. When the number of threads exceeds the number of > >>> CPU cores, we may get a lot of idle time. Then a workaround of > >>> MySQL is that do not creat threads which exceeds the number > >>> of CPU cores. Is it right? > >> Not really, that would make it impossible for MySQL to > >> handle more simultaneous database queries than the system > >> has CPUs. > >> > > > > I don't know myqsl internals, but you assume one thread per query. > > If its more like Apache, one long living thread for several connections ? > > Yes, they are longer lived client connections. One thread > per connection, just like Apache. > > > Its the same to answer 4+4 queries than 8 at half the speed, isn't it ? > > That still doesn't fix the potential Linux problem that this > benchmark identified. > > To clarify: I don't care as much about MySQL performance as > I care about identifying and fixing this potential bug in > Linux. Here http://people.freebsd.org/~kris/scaling/mysql.html Kris Kennaway talks about a patch for FreeBSD 7 which addresses poor scalability of file descriptor locking and that it's responsible for almost all of the performance and scaling improvements. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - 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: SMP performance degradation with sysbench
On Tue, 2007-02-27 at 09:02 -0500, Rik van Riel wrote: J.A. Magallón wrote: On Mon, 26 Feb 2007 23:31:29 -0500, Rik van Riel [EMAIL PROTECTED] wrote: Hiro Yoshioka wrote: Another question. When the number of threads exceeds the number of CPU cores, we may get a lot of idle time. Then a workaround of MySQL is that do not creat threads which exceeds the number of CPU cores. Is it right? Not really, that would make it impossible for MySQL to handle more simultaneous database queries than the system has CPUs. I don't know myqsl internals, but you assume one thread per query. If its more like Apache, one long living thread for several connections ? Yes, they are longer lived client connections. One thread per connection, just like Apache. Its the same to answer 4+4 queries than 8 at half the speed, isn't it ? That still doesn't fix the potential Linux problem that this benchmark identified. To clarify: I don't care as much about MySQL performance as I care about identifying and fixing this potential bug in Linux. Here http://people.freebsd.org/~kris/scaling/mysql.html Kris Kennaway talks about a patch for FreeBSD 7 which addresses poor scalability of file descriptor locking and that it's responsible for almost all of the performance and scaling improvements. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com - 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: 2.4.1-pre10 deadlock (Re: ps hang in 241-pre10)
At 15.40 27/01/01 -0800, you wrote:
>
>
>On Sat, 27 Jan 2001, Lorenzo Allegrucci wrote:
>>
>> A trivial "while(1) fork()" is enough to trigger it.
>> "mem=32M" by lilo, ulimit -u is 1024.
>
>Hmm.. This does not look like a VM deadlock - it looks like some IO
>request is waiting forever on "__get_request_wait()". In fact, it looks
>like a _lot_ of people are waiting for requests.
>
>So what happens is that somebody takes a page fault (and gets the mm
>lock), tries to read something in, and never gets anything back, thus
>leaving the MM locked.
>
>Jens: this looks suspiciously like somebody isn't waking things up when
>they add requests back to the request lists. Alternatively, maybe the
>unplugging isn't properly done, so that we have a lot of pending IO that
>doesn't get started..
>
>Ho humm. Jens: imagine that you have more people waiting for requests than
>"batchcount". Further, imagine that you have multiple requests finishing
>at the same time. Not unlikely. Now, imagine that one request finishes,
>and causes "batchcount" users to wake up, and immediately another request
>finishes but THAT one doesn't wake anybody up because it notices that the
>freelist isn't empty - so it thinks that it doesn't need to wake anybody.
>
>Lorenzo, does the problem go away for you if you remove the
>
> if (!list_empty(>request_freelist[rw])) {
> ...
> }
>
>code from blkdev_release_request() in drivers/block/ll_rw_block.c?
Yes, it does.
--
Lorenzo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-pre10 deadlock (Re: ps hang in 241-pre10)
At 15.40 27/01/01 -0800, you wrote:
On Sat, 27 Jan 2001, Lorenzo Allegrucci wrote:
A trivial "while(1) fork()" is enough to trigger it.
"mem=32M" by lilo, ulimit -u is 1024.
Hmm.. This does not look like a VM deadlock - it looks like some IO
request is waiting forever on "__get_request_wait()". In fact, it looks
like a _lot_ of people are waiting for requests.
So what happens is that somebody takes a page fault (and gets the mm
lock), tries to read something in, and never gets anything back, thus
leaving the MM locked.
Jens: this looks suspiciously like somebody isn't waking things up when
they add requests back to the request lists. Alternatively, maybe the
unplugging isn't properly done, so that we have a lot of pending IO that
doesn't get started..
Ho humm. Jens: imagine that you have more people waiting for requests than
"batchcount". Further, imagine that you have multiple requests finishing
at the same time. Not unlikely. Now, imagine that one request finishes,
and causes "batchcount" users to wake up, and immediately another request
finishes but THAT one doesn't wake anybody up because it notices that the
freelist isn't empty - so it thinks that it doesn't need to wake anybody.
Lorenzo, does the problem go away for you if you remove the
if (!list_empty(q-request_freelist[rw])) {
...
}
code from blkdev_release_request() in drivers/block/ll_rw_block.c?
Yes, it does.
--
Lorenzo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
swapoff and 2.4.0-prerelease
I run 'swapoff -a' in the middle of 'make j10 bzImage' with 32M (by lilo) and got this: Jan 3 17:30:07 lenstra kernel: VM: Undead swap entry 000f3100 Jan 3 17:30:07 lenstra kernel: VM: Bad swap entry 000f3100 Jan 3 17:30:07 lenstra kernel: VM: Bad swap entry 000f3100 Jan 3 17:30:07 lenstra kernel: Unused swap offset entry in swap_count 000f3100 Jan 3 17:30:07 lenstra kernel: VM: Bad swap entry 000f3100 I that moment the swap was about 20-25M. (ok, maybe swapoff by root is rather "unfair" but.. :-) -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
swapoff and 2.4.0-prerelease
I run 'swapoff -a' in the middle of 'make j10 bzImage' with 32M (by lilo) and got this: Jan 3 17:30:07 lenstra kernel: VM: Undead swap entry 000f3100 Jan 3 17:30:07 lenstra kernel: VM: Bad swap entry 000f3100 Jan 3 17:30:07 lenstra kernel: VM: Bad swap entry 000f3100 Jan 3 17:30:07 lenstra kernel: Unused swap offset entry in swap_count 000f3100 Jan 3 17:30:07 lenstra kernel: VM: Bad swap entry 000f3100 I that moment the swap was about 20-25M. (ok, maybe swapoff by root is rather "unfair" but.. :-) -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
A workload to detect fs corruption?
http://www.eecs.harvard.edu/~keith/usenix96/aging.tar.gz It's a good and 100% reproducible workload, I think. BTW, does test12 solve the fs corruption once and for all? -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
A workload to detect fs corruption?
http://www.eecs.harvard.edu/~keith/usenix96/aging.tar.gz It's a good and 100% reproducible workload, I think. BTW, does test12 solve the fs corruption once and for all? -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problem solved (WAS: lmbench on linux-2.4.0-test[4-11])
It was a trivial misconfiguration of my portmap and proxy. Sorry people and thank you for your patience :-) -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Problem solved (WAS: lmbench on linux-2.4.0-test[4-11])
It was a trivial misconfiguration of my portmap and proxy. Sorry people and thank you for your patience :-) -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lmbench on linux-2.4.0-test[4-11]
At 01.57 28/11/00 -0800, you wrote: > Date: Tue, 28 Nov 2000 11:08:17 +0100 > From: Lorenzo Allegrucci <[EMAIL PROTECTED]> > > Does anyone confirm this problem? > >Increase the space between the two numbers configured in >/proc/sys/net/ipv4/ip_local_port_range, try a configuration >such as: > >echo "32768 61000" >/proc/sys/net/ipv4/ip_local_port_range > >I bet the problem goes away then. ip_local_port_range already comes with such configuration. Anyhow, now even test1 shows the problem :-( I can run lmbench on 2.2.x kernels only. BTW, all local services (smtp, telnet etc) work well. Any ideas? -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
lmbench on linux-2.4.0-test[4-11]
About 2 times on 3 lmbench-2alpha12 stops at "Local networking". Below is a 'ps l': F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTYTIME COMMAND 100 0 207 1 9 0 1980 1204 wait4 Stty1 0:00 -bash 100 0 208 1 14 0 1968 1188 wait4 Stty2 0:00 -bash 000 0 209 1 9 0 1004 456 read_c Stty3 0:00 /sbin/getty 38400 tty3 000 0 210 1 9 0 1004 456 read_c Stty4 0:00 /sbin/getty 38400 tty4 000 0 211 1 9 0 1004 456 read_c Stty5 0:00 /sbin/getty 38400 tty5 000 0 212 1 9 0 1004 456 read_c Stty6 0:00 /sbin/getty 38400 tty6 000 0 4096 207 9 0 1168 588 wait4 Stty1 0:00 make results 000 0 4255 4096 9 0 1748 852 wait4 Stty1 0:00 /bin/sh ../scripts/results 000 0 4289 4255 9 0 1768 872 wait4 Stty1 0:00 /bin/sh ../../scripts/lmbench CONFIG.lenstra 040 0 4740 1 10 0 1000 292 tcp_da Stty1 0:00 lat_connect -s 040 0 4742 1 9 0 1068 380 wait_f Stty1 0:00 bw_tcp -s 000 0 4753 4289 10 0 1036 480 inet_w Stty1 0:00 lat_connect localhost 100 0 4761 208 17 0 2872 1256 - Rtty2 0:00 ps l lat_connect and bw_tcp are not running. It looks like a deadlock between connect() and accept(). 2.4.0-test[1-2] are not affected, don't know test3. Athlon UP machine. All kernels compiled with the same configuration and compiler, gcc 2.95.2 Does anyone confirm this problem? -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
lmbench on linux-2.4.0-test[4-11]
About 2 times on 3 lmbench-2alpha12 stops at "Local networking". Below is a 'ps l': F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTYTIME COMMAND 100 0 207 1 9 0 1980 1204 wait4 Stty1 0:00 -bash 100 0 208 1 14 0 1968 1188 wait4 Stty2 0:00 -bash 000 0 209 1 9 0 1004 456 read_c Stty3 0:00 /sbin/getty 38400 tty3 000 0 210 1 9 0 1004 456 read_c Stty4 0:00 /sbin/getty 38400 tty4 000 0 211 1 9 0 1004 456 read_c Stty5 0:00 /sbin/getty 38400 tty5 000 0 212 1 9 0 1004 456 read_c Stty6 0:00 /sbin/getty 38400 tty6 000 0 4096 207 9 0 1168 588 wait4 Stty1 0:00 make results 000 0 4255 4096 9 0 1748 852 wait4 Stty1 0:00 /bin/sh ../scripts/results 000 0 4289 4255 9 0 1768 872 wait4 Stty1 0:00 /bin/sh ../../scripts/lmbench CONFIG.lenstra 040 0 4740 1 10 0 1000 292 tcp_da Stty1 0:00 lat_connect -s 040 0 4742 1 9 0 1068 380 wait_f Stty1 0:00 bw_tcp -s 000 0 4753 4289 10 0 1036 480 inet_w Stty1 0:00 lat_connect localhost 100 0 4761 208 17 0 2872 1256 - Rtty2 0:00 ps l lat_connect and bw_tcp are not running. It looks like a deadlock between connect() and accept(). 2.4.0-test[1-2] are not affected, don't know test3. Athlon UP machine. All kernels compiled with the same configuration and compiler, gcc 2.95.2 Does anyone confirm this problem? -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lmbench on linux-2.4.0-test[4-11]
At 01.57 28/11/00 -0800, you wrote: Date: Tue, 28 Nov 2000 11:08:17 +0100 From: Lorenzo Allegrucci [EMAIL PROTECTED] Does anyone confirm this problem? Increase the space between the two numbers configured in /proc/sys/net/ipv4/ip_local_port_range, try a configuration such as: echo "32768 61000" /proc/sys/net/ipv4/ip_local_port_range I bet the problem goes away then. ip_local_port_range already comes with such configuration. Anyhow, now even test1 shows the problem :-( I can run lmbench on 2.2.x kernels only. BTW, all local services (smtp, telnet etc) work well. Any ideas? -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
lmbench-2alpha12 and linux-2.4.0-test11
It seems like lastest kernels cannot run lmbench successfully. lmbench stops at "Local networking", between lat_connect and bw_tcp, as far as I can see from 'top'. No errors reported, lat_connect or bw_tcp exit silently. All 2.4.0-test[5-11] seem to have this problem. 2.4.0-test1 and 2.2.x all run lmbench successfully instead. -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
lmbench-2alpha12 and linux-2.4.0-test11
It seems like lastest kernels cannot run lmbench successfully. lmbench stops at "Local networking", between lat_connect and bw_tcp, as far as I can see from 'top'. No errors reported, lat_connect or bw_tcp exit silently. All 2.4.0-test[5-11] seem to have this problem. 2.4.0-test1 and 2.2.x all run lmbench successfully instead. -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.17 & ASUS CD-S500/A (again)
At 13.40 28/10/00 -0700, you wrote: >On Sat, Oct 28 2000, Lorenzo Allegrucci wrote: >> I've got this while trying to play an audio CD by cdplay. > >[snip] > >> NOTE: >> 2.4.0-test9 works without problems. > >2.2.18-pre-latest will do then, could you try that? Yes, I've tried 2.2.18pre17, problem disappeared. Thanks for your help! -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.17 ASUS CD-S500/A (again)
At 13.40 28/10/00 -0700, you wrote: On Sat, Oct 28 2000, Lorenzo Allegrucci wrote: I've got this while trying to play an audio CD by cdplay. [snip] NOTE: 2.4.0-test9 works without problems. 2.2.18-pre-latest will do then, could you try that? Yes, I've tried 2.2.18pre17, problem disappeared. Thanks for your help! -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17 & ASUS CD-S500/A (again)
I've got this while trying to play an audio CD by cdplay.
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Invalid command operation code -- (asc=0x20, ascq=0x00)
The failed "Play Audio TrackIndex" packet command was:
"48 00 00 00 01 01 00 0a 63 00 00 00 "
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Invalid command operation code -- (asc=0x20, ascq=0x00)
The failed "Play Audio TrackIndex" packet command was:
"48 00 00 00 01 01 00 0a 01 00 00 00 "
cdplay: ioctl cdromplaytrkind
I can't play any CD under 2.2.17
2.2.17 bug or "Yet Another Bug Of S500/A" ? :-)
NOTE:
2.4.0-test9 works without problems.
--
Lorenzo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.17 ASUS CD-S500/A (again)
I've got this while trying to play an audio CD by cdplay.
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Invalid command operation code -- (asc=0x20, ascq=0x00)
The failed "Play Audio TrackIndex" packet command was:
"48 00 00 00 01 01 00 0a 63 00 00 00 "
hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
hdc: packet command error: error=0x54
ATAPI device hdc:
Error: Illegal request -- (Sense key=0x05)
Invalid command operation code -- (asc=0x20, ascq=0x00)
The failed "Play Audio TrackIndex" packet command was:
"48 00 00 00 01 01 00 0a 01 00 00 00 "
cdplay: ioctl cdromplaytrkind
I can't play any CD under 2.2.17
2.2.17 bug or "Yet Another Bug Of S500/A" ? :-)
NOTE:
2.4.0-test9 works without problems.
--
Lorenzo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
__alloc_pages: 1-order allocation failed
I've got the above message from 2.4.0-test10-1. Don't know test9 -- Lorenzo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
