Date: Sat, 14 Nov 2020 08:26:14 -0500 From: Alexander Motin <mav@FreeBSD.org> To: Hans Petter Selasky <hps@selasky.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: MAXPHYS bump for FreeBSD 13 Message-ID: <e44b6258-24e4-b28d-7139-0abf004a8b72@FreeBSD.org> In-Reply-To: <07a4ca53-da9d-e7b2-9af3-c5098f15a5c7@selasky.org> References: <1bff381f-3d6e-b20c-28f9-1403a9dfe0f6@FreeBSD.org> <07a4ca53-da9d-e7b2-9af3-c5098f15a5c7@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14.11.2020 06:22, Hans Petter Selasky wrote: > On 11/14/20 5:14 AM, Alexander Motin wrote: >>> We currently have a MAXPHYS of 128k. This is the maximum size of I/Os >>> that we normally use (though there are exceptions). >>> >>> I'd like to propose that we bump MAXPHYS to 1MB, as well as bumping >>> DFLTPHYS to 1MB. >> >> I am all for the MAXPHYS change, as Warner told it was my proposition on >> a chat. ZFS uses blocks and aggregates I/O up to 1MB already and can >> more potentially, and having I/O size lower then this just overflows >> disk queues, increases processing overheads, complicates scheduling and >> in some cases causes starvation. >> >> I'd just like to note that DFLTPHYS should probably not be changed that >> straight (if at all), since it is used as a fallback for legacy code. >> If it is used for anything else -- that should be reviewed and probably >> migrated to some other constant(s)> > Beware that many USB 2.0 devices will break if you try to transfer more > than 64K. Buggy SCSI implementations! Yes, thanks, I remember. The code reports MAXPHYS only for USB_SPEED_SUPER devices, relying on DFLTPHYS fallback in CAM otherwise. I think slower ones could just be hardcoded to 64KB to be certain. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e44b6258-24e4-b28d-7139-0abf004a8b72>