Date: Sat, 20 Mar 2010 17:20:09 +0200 From: Alexander Motin <mav@FreeBSD.org> To: FreeBSD-Current <freebsd-current@freebsd.org>, freebsd-arch@freebsd.org Subject: Increasing MAXPHYS Message-ID: <4BA4E7A9.3070502@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
Hi. With set of changes done to ATA, CAM and GEOM subsystems last time we may now get use for increased MAXPHYS (maximum physical I/O size) kernel constant from 128K to some bigger value. Increasing it allows to improve performance and reduce processing overhead for large I/O operations. Potential downside is a bit increased kernel memory usage, but as soon as these values were not changing for more than 8 years, I don't think it should be significant now. Present state of things: - ahci(4) and siis(4) support any I/O sizes up to MAXPHYS; - ata(4) supports I/O sizes up to min(512K, MAXPHYS) for the most of controllers, and works correctly for the rest; - most of SCSI controller drivers still limited by DFLTPHYS, but parts needed to work on them one by one later are already in place. - ad(4), da(4), ada(4), cd(4), acd(4), afd(4), atapicam(4) drivers support any I/O sizes, supported by underlying hardware and reported by ata(4) and cam(4) subsystems; - gmirror(4), gstripe(4), graid3(4), gconcat(4) were tested and fixed to support any I/O sizes up to MAXPHYS; All above I have successfully tested last months with MAXPHYS of 1MB on i386 and amd64 platforms. So my questions are: - does somebody know any issues denying increasing MAXPHYS in HEAD? - are there any specific opinions about value? 512K, 1MB, MD? -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BA4E7A9.3070502>