The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: sms@2BSD.COM (Steven M. Schultz)
Subject: [pups] Progress on 2.11BSD kernel
Date: Wed, 19 Mar 2003 15:08:46 -0800 (PST)	[thread overview]
Message-ID: <200303192308.h2JN8kD04865@moe.2bsd.com> (raw)

Hi -

> From: David Evans <dfevans at bbcr.uwaterloo.ca>
> 
>   OK.  From what I recall (that turned-off machine again...) the entire
> discussion on tuning MAXUSERS and friends is based on allocation of UMRs.
> Might be a good idea to slip in a note about what to do when you don't have

	It is less a matter of MAXUSERS than it is of NBUF.   NBUF sets
	the number of disc cache buffers.   MAXUSERS affects the size of the
	proc table, file table, and other tables which are in the permanent
	(not mapped in/out) portion of the kernel's address space but does 
	not affect the disc buffer cache which is the entity requiring UMRs
	on a UNIBUS system.

	The buffer cache must be entirely mapped by UMRs - so if you have a 
	32KB buffer the kernel will reserve 4 UMRs on a UNIBUS system.   
	Realistically a 64KB buffer cache is about the maximum a UNIBUS system 
	can have because that takes 8 of the UMRs.  

	With the old (thankfully no longer in use, etc) 3Com ethernet boards
	you had to disable 4 UMRs so the system could access the memory in the
	card - that made for a very tight fit.

	The other constraint, even for Qbus systems, is the D space requirement.
	The 1KB portion of the disc buffer is "external" to the kernel (is 
	mapped in/out as needed) but there is a header structure which is
	part of the kernel's permanent address space.  Each buffer header is
	24 bytes so even without UMRs around it's not feasible to have a 200KB
	cache because that'd use 4800 bytes of kernel D space (which is always
	on the edge of being overflowed it seems).

	On a 11/73 I've used a 100KB buffer cache but when I was using 11/44s
	and /70s the max was 64KB.

	Cheers,
	Steven Schultz



             reply	other threads:[~2003-03-19 23:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-19 23:08 Steven M. Schultz [this message]
2003-03-19 23:15 ` David Evans
2003-03-19 23:34 ` Johnny Billquist
  -- strict thread matches above, loose matches on Subject: below --
2003-03-21 18:33 Steven M. Schultz
2003-03-21 18:26 Steven M. Schultz
2003-03-19 23:52 Steven M. Schultz
2003-03-19 19:09 Steven M. Schultz
2003-03-19 19:30 ` David Evans
2003-03-19 19:06 Carl Lowenstein
2003-03-19 19:14 ` David Evans
2003-03-19 20:12 ` David C. Jenner
2003-03-19 17:51 Steven M. Schultz
2003-03-19 18:08 ` David Evans
2003-03-19 17:36 Steven M. Schultz
2003-03-19 17:46 ` David Evans
2003-03-19 18:24 ` Ian King
2003-03-19 18:59   ` David Evans
2003-03-21 18:08 ` Ian King
2003-03-19  7:44 Ian King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200303192308.h2JN8kD04865@moe.2bsd.com \
    --to=sms@2bsd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).