From owner-freebsd-current Mon Feb 15 07:11:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA16037 for freebsd-current-outgoing; Mon, 15 Feb 1999 07:11:27 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA16024 for ; Mon, 15 Feb 1999 07:11:25 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id CAA00760; Tue, 16 Feb 1999 02:11:18 +1100 Date: Tue, 16 Feb 1999 02:11:18 +1100 From: Bruce Evans Message-Id: <199902151511.CAA00760@godzilla.zeta.org.au> To: bde@zeta.org.au, dillon@apollo.backplane.com Subject: Re: Weird piecemeal reads over socketpair() pipe breaks up small writes into even smaller reads. Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok, so perhaps tweeking the rescheduling changes in kern_subr.c to > not try to do it in the first few thousand bytes copied is the solution? kern_subr.c can't do that, because `struct uio' doesn't give the original count. > Would you like to do it or should I? This isn't high priority but it > should definitely not be rescheduling after the first 96 bytes. That's > just a waste of cpu. The waste for rescheduling should be insignificant, since it should only occur every ROUNDROBIN_INTERVAL (default 100 msec). It actually seems to be rescheduling more often. Rescheduling _after_ the first 96 bytes is surprising, since the rescheduling is done before doing any i/o, so sync effects from sleep(1) should cause rescheduling before any i/o is done. Then the reader won't run, but other processes may. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message