Qouting Jukka Marin,

> >Um, avoiding at least one of the copies from mbuf to clist to output
> >silo on the way out?
> 
> Speaking utterly without numbers: if the copies are done in large
> chunks (an mbuf at a time) the effect is going to very small.  Down
> there in the noise, on machines with ~70Mbyte/sec write bandwidth.

>Tell that to my Amiga 3000 - or even my SS1's.  Sure, on a P6/200 you
>won't notice the load of one pppd, but try running 16 or 32 pppd's on
>a slower machine.... ;)  See, all of us can't afford upgrading our
>machines every year.  (This applies to all possible optimizations -
>there are people who will notice the speed up of any real improvement.

Jukka,

I hope it's clear that what I said was that the cost of the
_extra copies_ Dennis referred to was going to be down in the noise.
That says nothing about the costs of running that many pppds.

I did say that the cost of two copies, rather than one, between mbuf
and output silo was going to be in the noise.  I never said running 16
or 32 pppds wasn't going to load a machine.  Those are not the same
thing at all.

Now, lets' suppose you really  have machines with 16 or 32 serial ports.
what's the aggregage rate of those ports?  I'll assume 115200 bps.

Assuming 115200 bps lines,  and multiplying the numbers out, while
allowing for start and stop bits, I get an aggregate of 368640
bytes/sec,  in each direction.

My claim is that, if the copies are done in large sizes, you're
__not__ going to notice a significant difference between copying that
much data once, and copying it twice, not on any reasonable machine.
Is that clearer now?

Now, if you were measuring this on say a VAX-11/750 or, perhaps, on a
slow Sun-3, you might notice a difference. But serial ports on those
older, slower CPUs machines run an order of magnitude slower.  If we
assume 38400 baud (faster than most vax serial ports can go), you're
still only talking about a marginal 122880 kbyte copy, not a 300kbyte
copy.  And since we're assuming the serial ports are running flat-out,
then assuming an MTU-sized copy (e.g.,256 bytes) seems quite
reasonable.

(Again, as I said in my earlier message, this is done completely
without acutally having measured numbers, so I could be talking utter
nonsense.  But back-of-the-envelope calculations, as above, suggest
otherwise.)


Of course, that says nothing about the costs of running 16 or 32
pppds. That may be a different story.  OK?


If running that many pppds is pushing your systems into the ground,
build a kernel with profiling, run with profiling on for half an hour,
and find out where the time is going.  Analyze the results, understand
where the bottlenecks are, and tune the misperforming code paths (or
use better algorithms).  Repeat, ad nauseam.

Unless someone has already paid attention to kernel profiling on the
port you're using, you may run into problems (e.g. the kernel locore
functions aren't instrumented) which make this harder than it need
be. But J.T. is actively doing kernel profiling on at least one m68k
ports, so this shouldn't be too hard to get fixed.

OTOH, If you're running 30 concurrent  processes on an  SS1,
you're probably thrashing  pmegs.


>Speaking of which - is there anything that could be done to speed up
>starting new processes?  Running shell scripts is very slow on my Amiga
>(and one running shell script almost stops all other processes on the
>system).

See above. Quite seriously.

But, _if_ you're running 1.2, _and_ your machine is exhausting
physical memory (as shown by, e.g., a concurrent systat vmstat),
then I'd suggest you try replacing the 1.2 sys/vm/vm_pageout.c with
the -current version:


*** /usr/src/sys-1.2/vm/vm_pageout.c	Mon Feb  5 04:26:54 1996
--- /usr/src/sys/vm/vm_pageout.c	Mon Oct 14 09:53:47 1996
***************
*** 1,4 ****
! /*	$NetBSD: vm_pageout.c,v 1.23 1996/02/05 01:54:07 christos Exp $	*/
  
  /* 
   * Copyright (c) 1991, 1993
--- 1,4 ----
! /*	$NetBSD: vm_pageout.c,v 1.24 1996/09/18 02:04:50 mrg Exp $	*/
  
  /* 
   * Copyright (c) 1991, 1993
***************
*** 70,75 ****
--- 70,76 ----
  
  #include <sys/param.h>
  #include <sys/proc.h>
+ #include <sys/kernel.h>
  
  #include <vm/vm.h>
  #include <vm/vm_page.h>
***************
*** 319,332 ****
  		break;
  	case VM_PAGER_AGAIN:
  	{
- 		extern int lbolt;
- 
  		/*
  		 * FAIL on a write is interpreted to mean a resource
  		 * shortage, so we put pause for awhile and try again.
  		 * XXX could get stuck here.
  		 */
! 		(void) tsleep((caddr_t)&lbolt, PZERO|PCATCH, "pageout", 0);
  		break;
  	}
  	case VM_PAGER_FAIL:
--- 320,332 ----
  		break;
  	case VM_PAGER_AGAIN:
  	{
  		/*
  		 * FAIL on a write is interpreted to mean a resource
  		 * shortage, so we put pause for awhile and try again.
  		 * XXX could get stuck here.
  		 */
! 		(void) tsleep((caddr_t)&vm_pages_needed, PZERO|PCATCH,
! 		    "pageout", hz);
  		break;
  	}
  	case VM_PAGER_FAIL:
***************
*** 451,459 ****
  	 * XXX rethink this
  	 */
  	if (postatus == VM_PAGER_AGAIN) {
! 		extern int lbolt;
! 
! 		(void) tsleep((caddr_t)&lbolt, PZERO|PCATCH, "pageout", 0);
  		goto again;
  	} else if (postatus == VM_PAGER_BAD)
  		panic("vm_pageout_cluster: VM_PAGER_BAD");
--- 451,458 ----
  	 * XXX rethink this
  	 */
  	if (postatus == VM_PAGER_AGAIN) {
! 		(void) tsleep((caddr_t)&vm_pages_needed, PZERO|PCATCH,
! 		    "pageout", hz);
  		goto again;
  	} else if (postatus == VM_PAGER_BAD)
  		panic("vm_pageout_cluster: VM_PAGER_BAD");