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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
