In message <199905081700.DAA07665@wombat.cs.rmit.edu.au>,
Luke Mewburn writes:

>Hi all...
>
>Whilst looking at which ports supported the `BUFCACHE' option (with
>intent to convert the remaining ports), I noticed that most ports
>had a MD allocsys() function, which (amongst other things) calculates
>and then allocates the memory to be used by the buffer cache.
>
>I decided to see how hard it would be to make this function MI; 
>it was fairly simple.

Cool! I'd looked at this before the 1.4 cycle, but got bogged down in
other things.  Just a few comments:

* Several ports have code to allocate MD structures (alpha per-cpu
  machine-check blocks, sparc dvmamaps, whatever). You moved this
  to the tail of the MI allocsys(), with per-CPU #ifdefs..

  Why not  add an MD callback, with the same signature as
  the existing MD allocsys(), and call that on ports where it's
  needed (and thus #define'd)?

* Is it wise to be merging this code whilst there's an open PR
  against i386 systems with >= 1 Gig of RAM? Overly-large buffers
  exhausting KVM (ala nkpdes) has to be the first suspect, here.

* Systems with a Gbyte or more of RAM will only become more common.
   If we're going to have a single routine to handle these, isnt it time
   to start printing the output in megabytes, at least?
   At least when buffer size crosses some threshhold?

* VM_MAX_KERNEL_BUF is #define'd as
   ((VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS)  * MAGIC / 10)
  on all ports that use it, where MAGIC is either 4 (arm32) or 7 (386,pc532).
  why those particular magic constants?  What hardware  features (if any)
  do they depend on? What they should be for, e.g., mips?
  How about we wrap the buffer-limit code in #ifdef VM_MAX_KERNEL_BUF for now?