On Mon, 2 May 2011 06:40:31 -0600 "Asai Thambi Samymuthu Pattrayasamy (asamymuthupa) [CONTRACTOR]" <asamymuthupa@xxxxxxxxxx> wrote: > > The kernel starting point would be that we have an AHCI driver. If you > > need workarounds for hardware errata then they can go into it and that > is > > fine. We support NCQ so we can use the queue depths. If there are > > extensions then the AHCI driver can be enhanced. > > We understand that AHCI driver can be patched for hardware errata and > other customizations, but main concern is performance. Yes I understand that - but our main concern is maintainability, which means one driver per AHCI flash vendor is a mess that isn't practicable to deal with. Documenting the errata would be a help anyway so we can get them into the mainline AHCI driver, irrespective of what drivers we end up with ultimately. > > I think the starting point would be to explain what problems you see > with > > the existing driver, and where the profiling tools say the bottlenecks > > are when you try and get full speed under libata + libata ahci driver. > > The performance difference is not just because of libata + libata ahci > driver. Our driver gets the request before elevator comes into picture. > So, the stack starting from elevator,scsi upper, scsi mid, libata and > libata ahci driver attributes to the performance difference. Elevator for flash devices should automatically be null and most of the SCSI layer isn't actually used so it would be interesting to know for example what shows up in comparative profiles so that it can be optimised or dropped out. Alan -- 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
