13 Oca 2007 Cts 03:12 tarihinde, Tejun Heo şunları yazmıştı:
Hello,
Hello,
Thanks for the response.
[...]
Does everything else work okay?
Can you access devices attached to
ahci?
Yes. While the machine is on, there seems to be no problem at all. Everything
works great.
What
On Friday 12 January 2007 10:50, Mark Hounschell wrote:
Mark Hounschell wrote:
I have a Tyan S4881 Thunder K8QW 4 processor (8 cores). Kernel 2.6.16.37
boots
and runs fine.
However kernel 2.6.17 and up doesn't. Here is my boot error msg.
kernel /vmlinuz-2.6.17-smp
Justin Piszcz wrote:
Using 4 raptor 150s:
Without the tweaks, I get 111MB/s write and 87MB/s read.
With the tweaks, 195MB/s write and 211MB/s read.
Using kernel 2.6.19.1.
Without the tweaks and with the tweaks:
# Stripe tests:
echo 8192 /sys/block/md3/md/stripe_cache_size
# DD
On Fri, 12 Jan 2007, Michael Tokarev wrote:
Justin Piszcz wrote:
Using 4 raptor 150s:
Without the tweaks, I get 111MB/s write and 87MB/s read.
With the tweaks, 195MB/s write and 211MB/s read.
Using kernel 2.6.19.1.
Without the tweaks and with the tweaks:
# Stripe tests:
RAID 5 TWEAKED: 1:06.41 elapsed @ 60% CPU
This should be 1:14 not 1:06(was with a similarly sized file but not the
same) the 1:14 is the same file as used with the other benchmarks. and to
get that I used 256mb read-ahead and 16384 stripe size ++ 128
max_sectors_kb (same size as my sw raid5
Justin Piszcz wrote:
RAID 5 TWEAKED: 1:06.41 elapsed @ 60% CPU
This should be 1:14 not 1:06(was with a similarly sized file but not the
same) the 1:14 is the same file as used with the other benchmarks. and to
get that I used 256mb read-ahead and 16384 stripe size ++ 128
max_sectors_kb
On Fri, 12 Jan 2007, Al Boldi wrote:
Justin Piszcz wrote:
RAID 5 TWEAKED: 1:06.41 elapsed @ 60% CPU
This should be 1:14 not 1:06(was with a similarly sized file but not the
same) the 1:14 is the same file as used with the other benchmarks. and to
get that I used 256mb read-ahead and
Btw, max sectors did improve my performance a little bit but
stripe_cache+read_ahead were the main optimizations that made everything
go faster by about ~1.5x. I have individual bonnie++ benchmarks of
[only] the max_sector_kb tests as well, it improved the times from 8min/bonnie
run - 7min
Justin Piszcz wrote:
# echo 3 /proc/sys/vm/drop_caches
# dd if=/dev/md3 of=/dev/null bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 399.352 seconds, 26.9 MB/s
# for i in sde sdg sdi sdk; do echo 192
/sys/block/$i/queue/max_sectors_kb; echo Set
Justin Piszcz wrote:
Btw, max sectors did improve my performance a little bit but
stripe_cache+read_ahead were the main optimizations that made everything
go faster by about ~1.5x. I have individual bonnie++ benchmarks of
[only] the max_sector_kb tests as well, it improved the times from
On Sat, 13 Jan 2007, Al Boldi wrote:
Justin Piszcz wrote:
Btw, max sectors did improve my performance a little bit but
stripe_cache+read_ahead were the main optimizations that made everything
go faster by about ~1.5x. I have individual bonnie++ benchmarks of
[only] the max_sector_kb
Justin Piszcz wrote:
On Sat, 13 Jan 2007, Al Boldi wrote:
Justin Piszcz wrote:
Btw, max sectors did improve my performance a little bit but
stripe_cache+read_ahead were the main optimizations that made
everything go faster by about ~1.5x. I have individual bonnie++
benchmarks of
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Horms
Sent: 2007年1月12日 14:07
To: Vivek Goyal
Cc: Mohan Kumar M; Andrew Morton; Zou, Nanhai; Luck, Tony;
linux-kernel@vger.kernel.org; fastboot@lists.osdl.org;
linux-ia64@vger.kernel.org
Subject:
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation
Horms [EMAIL PROTECTED] writes:
+ If the start address is specified, not that the start address of the
note
+ kernel will be alligned to 64Mb, so any if the start address is not then
aligned XXX
+ any space below the
Horms wrote:
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation
On Fri, Jan 12, 2007 at 11:46:39AM -0800, Jay Lan wrote:
Horms wrote:
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point,
This email lists some known regressions in 2.6.20-rc5 compared to 2.6.19
with patches available.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any
On Fri, Jan 12, 2007 at 02:27:48PM -0500, Linus Torvalds wrote:
...
A lot of developers (including me) will be gone next week for
Linux.Conf.Au, so you have a week of rest and quiet to test this, and
report any problems.
Not that there will be any, right? You all behave now!
...
This
501 - 520 of 520 matches
Mail list logo
