On Mar 27, 2013, at 4:13 PM, Matthew Jacob <mjacob_at_FreeBSD.org> wrote: > On 3/27/2013 2:22 PM, Alexander Motin wrote: >> Hi. >> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. >> >> Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Does anybody have good ideas why we should not drop it now? >> > Some people have expressed performance concerns about ATA_CAM. I have not validated those concerns. Does anyone know of any? The albatross of "CAM is slow" comes up over and over, but I never see any data to support the claims. So here's an anecdote of my own. Several years ago, Paul Saab and I were looking at performance problems with the CISS driver. To rule out the "CAM is slow" argument, he wrote a shim for it that completely cut out CAM and gave it a thin block layer attachment. The result was that his new driver was actually _slower_ than the CAM driver. Why? CAM scheduler actually does a really good job with keeping the pipeline to the driver full and free of stalls. Also, the code overhead of going through CAM is also much smaller than people assume, likely because no one actually reads the code before they make the assumption. ScottReceived on Thu Mar 28 2013 - 14:52:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:36 UTC