On Fri, Jan 12, 2007 at 02:45:23PM -0500, Dailey, Nate wrote: > Hoping someone on this list might shed some light on this... > > I was investigating a problem of poor sequential write performance > (IOmeter, various size sequential writes) with an embedded Vitesse 7174, > maxing out (with disk write cache on) at around 10 MB/s... > > After noticing that Windows on the same hardware was using 0x10 for the > cache line size, but Linux was using 0x80, I tried removing the > following from sata_vsc.c: > > 381 /* > 382 * Due to a bug in the chip, the default cache line size > can't be used > 383 */ > 384 pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x80); > > Now, with cache line size the same as Windows, Linux is doing more like > 43 MB/s. > > Just wondering what the deal with this "bug in the chip" might be, since > for me it seems that the default cache line size is better? If there's a > real bug, I don't want to do anything dangerous by removing this code > (though I've heard--haven't seen the code--that the Windows driver > doesn't touch the cache line size, nor does the Linux non-libata > reference driver from Vitesse). The problem is that it can't be zero, which is the default value after reset. So I suppose the driver should be modified to set it to 0x80 only if it's 0. I believe that most PCI implementations will set it in the BIOS or whatever. Care to send a patch? jeremy - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
