Date: Wed, 22 Sep 1999 22:48:53 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: mjacob@feral.com Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_physio.c src/sys/miscfs/specfs spec_vnops.c src/sys/sys conf.h Message-ID: <35615.938033333@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 22 Sep 1999 13:35:15 PDT." <Pine.BSF.4.05.9909221311520.581-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.05.9909221311520.581-100000@semuta.feral.com>, Matthew J acob writes: >Should si_iosize_max be cognizant of all limitations (e.g., HBA DMA >limitations)? Depends on the driver really. I have not checked all the drivers to see what they do if they get a request larger than their stated or default si_iosize_max. I think they should loop over the buf and try to carry it all out. The right description of this field really might be "a transaction larger than this size cannot be carried out in one operation, so don't bother clustering more than that." So in other words: this is a performance tweaking handle for the driver, it (hopefully) isn't a hard limit on transaction site. All I've done here btw, is to move it from cdevsw where it is "per device driver" to dev_t where it is per device. >Can si_iosize_max be a sized integer? If by this you mean that it should be number of DEV_BSIZE sectors the answer is no, there is/should be nothing which limit us to sectors of DEV_BSIZE (think audio CDs). I don't think a transaction size limit of ~1GB is going to be a limitation in the near future. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35615.938033333>