From owner-freebsd-current Mon Feb 15 11:09:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA15300 for freebsd-current-outgoing; Mon, 15 Feb 1999 11:09:28 -0800 (PST) (envelope-from owner-freebsd-current@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 LAA15291 for ; Mon, 15 Feb 1999 11:09:26 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA18526; Mon, 15 Feb 1999 10:58:19 -0800 (PST) (envelope-from dillon) Date: Mon, 15 Feb 1999 10:58:19 -0800 (PST) From: Matthew Dillon Message-Id: <199902151858.KAA18526@apollo.backplane.com> To: Bruce Evans Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG Subject: Re: Weird piecemeal reads over socketpair() pipe breaks up small writes into even smaller reads. References: <199902151511.CAA00760@godzilla.zeta.org.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 sleep() is not relevant... what is relevant is that the sub-process is doing a write() while the parent is sitting in a select() -- the parent process is thus going to have priority over the child. The moment the child allows a reschedule, the parent gets the cpu. I would like to point out that this type of situation will occur with most piping situations. The reader is almost always blocked waiting to read while the writer is obviously always running, in the middle of the write. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message