On Mar 27, 2013, at 4:13 PM, Matthew Jacob <mja...@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. Scott _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
