From owner-freebsd-hackers Mon Jan 11 16:30:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA26489 for freebsd-hackers-outgoing; Mon, 11 Jan 1999 16:30:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA26484 for ; Mon, 11 Jan 1999 16:30:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id QAA98242; Mon, 11 Jan 1999 16:29:38 -0800 (PST) (envelope-from dillon) Date: Mon, 11 Jan 1999 16:29:38 -0800 (PST) From: Matthew Dillon Message-Id: <199901120029.QAA98242@apollo.backplane.com> To: Matthew Jacob Cc: Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: what is the meaning of this useless code? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> On Mon, 11 Jan 1999, Matthew Jacob wrote: :> > if (resid > maxio) :> > resid = maxio; :> > :> > return getpbuf(); :> > } :> > :> > why is resid being truyncaated and maxio being set when this has no :> > effect? :> :> I think resid was originally an agument to getpbuf :> but mechanical edits have turned it all into a NOP. :> Good catch.. : :Okay. This is definitely a junk assignment. :> However there is a related problem.. :> :> the maximum IO size allowed for a device is kept in the :> cdevsw entry, which is the WRONG place, because :> it cannot correctly reflect the case when there are two differnt devices :> with different limits on the same controller (e.g. two different drives :> or even two differend controllers on one driver). :> : :Well, there are a number of limits- some are device specific, some are bus :specific and some are VM/OS specific. It's a bit confusing which applies :here. : :I'm going to ponder this as time permits. I'm trying to track down a hang :on alpha with larget I/Os and this led me to try and follow the raw I/O :path which led to this... The (struct buf *)->b_pages[] array is limited to MAXPHYS bytes worth of pages, where MAXPHYS is typically 128 KBytes. If you try to stuff a struct buf with more then that, you will overrun the array and bad things will happen. Make sure the devices properly limit the size of the I/O operation they try to stuff into a struct buf. This is just one of several limits, as you know. d_maxio could probably be removed from the kernel entirely with a little work. I wouldn't worry about it too much, all that really matters is that the value is large enough such that the transaction rate does not overburden the device. For a hard disk, anything over 8KBytes tends to accomplish this. -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message