![]() | ||||||||||
Messages in this thread |
Hi Alan, Alan Cox wrote: >>> In Your oprofile output I find "acpi_pm_read" particulary interesting. >>> Unlike other VIA chipsets, which I know, Your doesn't use VLink to >>> connect northbridge to southbridge. Instead PCI bus connects these two. >>> As You probably know maximal PCI throughtput is 133MiB/s. In theory. In >>> practice probably less. > > acpi_pm_read is capable of disappearing into SMM traps which will make > it look very slow. what is an SMM trap? I googled a bit but didn't get it... > >> about 15MB/s for both disks. When reading I get about 30MB/s again from >> both disks. The other disk, the small one, is mostly idle, except for >> writing little bits and bytes now and then. Since the problem occurs >> when writing, 15MB/s is just too little I think for the PCI bus. > > Its about right for some of the older VIA chipsets but if you are seeing > speed loss then we need to know precisely which kernels the speed dropped > at. Could be there is an I/O scheduling issue your system shows up or > some kind of PCI bus contention when both disks are active at once. I am sure throughput kept diminishing little by little with many 2.6 releases, and that it wasn't a major regression on a specific version. Unfortunately I cannot backup my words with measurements from older kernels right now, since the system is hard to boot with such (new udev, new glibc). However I promise I'll test in the future (probably using old liveCDs) and come back then with proof. > >> I have been ignoring these performance regressions because of no >> stability problems until now. So could it be that I'm reaching the >> 20MB/s driver limit and some requests take too long to be served? > > Nope. the reason I'm talking about a "software driver limit" is because I am sure about some facts: - The disks can reach very high speeds (60 MB/s on other systems with udma5) - The chipset on this specific motherboard can reach much higher numbers, as was measured with old kernels. - No cable problems (have been changed), no strange dmesg output. So what is left? Probably only the corresponding kernel module. Thanks, Dimitris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2007-08-06 21:43 [W:0.337 / U:0.510 seconds] ©2003-2008 Jasper Spaans | ||||||||||