From owner-freebsd-current Wed Mar 4 22:38:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA14654 for freebsd-current-outgoing; Wed, 4 Mar 1998 22:38:43 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA14573; Wed, 4 Mar 1998 22:37:24 -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 RAA05933; Thu, 5 Mar 1998 17:27:31 +1100 Date: Thu, 5 Mar 1998 17:27:31 +1100 From: Bruce Evans Message-Id: <199803050627.RAA05933@godzilla.zeta.org.au> To: dmaddox@scsn.net, dyson@FreeBSD.ORG Subject: Re: silo overflows (Was Re: 3.0-RELEASE?) Cc: current@FreeBSD.ORG, evanc@synapse.net, Matthew.Thyer@dsto.defence.gov.au, mike@smith.net.au, shimon@simon-shapiro.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I don't think that the MSIZE option is really needed. If we can >get approval from BDE, or if he would "correct" the suggestion, >the I'll commit it for him. The problem with increasing TTYHOG is that it would waste up to about 2 * (NEW_TTYHOG - OLD_TTYHOG) bytes for (active) ttys that don't need it, in particular for ptys. Systems with a huge number of ptys are more likely to have wired almost all kernel memory already. >> Index: sio.c >> =================================================================== >> RCS file: /local/home/ncvs/src/sys/i386/isa/sio.c,v >> retrieving revision 1.194 >> diff -r1.194 sio.c >> 117a118 >> > /* >> 119a121,123 >> > */ >> > #define RB_I_HIGH_WATER (TTYHOG / 2) >> > #define RS_IBUFSIZE (TTYHOG / 4) In previous mail, I confused RB_I_HIGH_WATER with RS_IHIGHWATER and said that it was wrong. It is OK, but there is another copy of it in tty.c (named I_HIGH_WATER) to change. My version sets all the buffer sizes and watermarks dynamically. I haven't decided the right policy. I currently allocate buffers large enough to hold one second's worth of i/o (e.g., 46K for 4 * 115200 bps). This is wasteful, especially for output. When I last looked at it a few months ago, I got sidetracked looking at anomalous output for large output buffers... It didn't seem to be urgent to finish it :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message