On Sun, May 20, 2007 12:19, Tejun Heo wrote:
> Indan Zupancic wrote:
>> On Sun, May 20, 2007 00:03, Jeff Garzik wrote:
>>> Indan Zupancic wrote:
>>>> This patch seems to work with my SiI 3512, though I don't notice any
>>>> difference, neither a speedup, nor a slowdown. Hdparm gives the same
>>>> speeds (-tT), and cp -a'ing kernel sources is abysmal slow in both cases,
>>>> (need to look into that one) so I didn't really test it that well.
>>>
>>> It won't result in much of a speedup, except in situations where IOMMU
>>> or other situation that causes you to run into the 64k boundary being an
>>> issue -- generally only on huge transfers.
>>>
>>> A good measure is to dd(1) to/from the block device, rather than using a
>>> filesystem. As has been shown on LKML, the filesystem can really slow
>>> things down in some cases.
>>
>> I didn't really expect a speedup, it's more that I've no regression to report.
>>
>> I could benchmark the patch more thoroughly, but right now I'm more worried
>> about the crawling cp I just discovered. Talking about filesystems slowing down
>> things...
>>
>> Test:
>>
>> $ cp -a linux-2.6/ /tmp/
>>
>> done on the same ext3 partition. linux-2.6 contains source and git repo only,
>> I'm compiling stuff with O=../obj.
>>
>> $ vmstat 10
>> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
>> r b swpd free buff cache si so bi bo in cs us sy id wa
>> 0 1 0 4168 3316 195700 0 0 739 494 530 393 15 3 66 16
>> 0 3 4 4120 2040 198196 0 0 14677 14111 1247 435 0 17 0 83
>> 0 1 4 3588 1444 199696 0 0 8892 9472 1362 438 0 12 0 88
>> 1 0 4 3772 4228 196012 0 0 764 454 1161 345 0 4 0 96
>> 0 1 4 3548 6156 193088 0 0 793 851 1158 340 0 4 0 96
>> 0 1 4 3852 7608 189096 0 0 798 523 1160 474 1 4 0 95
>> 1 1 4 3612 8684 186048 0 0 1244 864 1178 430 2 5 0 93
>> 0 1 4 90660 9308 96396 0 0 853 906 1244 578 7 6 0 87
>> 0 1 4 72280 9816 112368 0 0 830 854 1278 429 12 5 0 83
>> 1 0 4 52488 10296 130560 0 0 935 861 1178 418 1 6 0 94
>> 0 1 4 30500 10788 149776 0 0 977 858 1178 371 0 6 0 94
>> 0 1 4 9792 11244 167856 0 0 918 1394 1182 350 1 5 0 94
>> 0 1 4 4016 11216 172504 0 0 1017 858 1181 382 1 6 0 94
>> 0 1 4 3660 11484 171484 0 0 966 861 1182 410 1 6 0 94
>>
>> It never finished, as I had no patience to copy about 900 Mb with this rate.
>>
>> As it's a git tree, I suppose it's heavily fragmented, but this is still rather
>> pathetic. Should I blame cp, or is something else wrong? Any ideas how
>> to figure this one out would be appreciated. Sorry for the off-topicness.
>
> Do things improve if you change the io scheduler to deadline?
>
> # echo deadline > /sys/block/sda/queue/scheduler
I also tried noop, anticipatory, and now deadline, but it doesn't matter.
> Also worth looking at is the following bug entry.
>
> http://bugzilla.kernel.org/show_bug.cgi?id=7372
>
> There seems to be weird interaction among the scheduler / VM / IO. The
> exact cause is still not verified. :-(
I know, I posted a bugreport too, but for starvation with the anticipatory scheduler.
Anyway, that bug seems unrelated to my case, as they have system unresponsiveness
or other nastiness, while I only have a crawling cp, which I blame on weaknesses
within ext3, a badly designed cp program and very fragmented filesystem. I just need
to verify that, somehow. I'll try with older kernels later.
Greetings,
Indan
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
