Subject: Re: moving allocsys() into MI part of kernel
To: None <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 05/08/1999 13:01:16
In message <199905081700.DAA07665@wombat.cs.rmit.edu.au>,
Luke Mewburn writes:
>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?