On Sat, Oct 30, 2004 at 10:50:22AM +0300, Arto Selonen wrote:
> Hi!
> 
> On Sat, 30 Oct 2004, enami tsugutomo wrote:
> 
> > > Perhaps is it better to change the calculation of (uvmexp.active +
> > > uvmexp.inactive + uvmexp.free) in uvmpd_scan_inactive() to
> > > uvmexp.npages?
> >
> > I don't think it's better since pagedaemon can do something only for
> > pages on the queues.

right, that's why I wrote it the way I did.  I agree that it's a little
unintuitive, but the other way seems less useful.


> It may only work with the queues, but *why* do those min,max limits exist?
> Why does pagedaemon reactivate pages from inactive queue based on those
> limits? Those who understand UVM probably know, I can only guess.
> And te way I read the limits is that they are a way for the system admin
> to tell the system, what sort of a balance of different page types
> (anon, exec, file) the VM subsystem should keep resident.

that's exactly it.  without something like this, cached file pages will
force everything else out of memory pretty quickly, since in typical usage
patterns the number of file pages that are accessed far exceeds the number
of anonymous pages and the number of physical pages, by enough to defeat the
traditional double-LRU page replacement scheme.


> The documentation makes sense to me (as I don't know any better), but the
> code does not.
> 
> One third of available memory could be wired, kernel seems to take ~10%,
> so whatever limits are given, in reality the limits used could be
> over 60% smaller than what was thought. And the limits keep changing!
> That is a very bad premise for precise control of memory usage.
> (And I would prefer precise control with a loaded gun pointed to my
> virtual foot, over fuzzy guess work that is safe). :)
> 
> However, since I can not possibly understand all possible scenarios
> and aspects of UVM behaviour, I certainly don't want to argue
> "it should be so". I am merely trying to point out that from
> a user's point of view, the current min,max limits are quite
> difficult to use, and they would be more useful for the user, if used
> differently. In any case, either code or documentation needs changing.

the currently knobs to adjust the balance are just what I came up with,
if we find a better set of knobs (or better semantics for the current ones),
then I'm all for switching.  but it's harder than it seems it should be.
failing that, improving the documentation would also be good.
the current documentation is really just the few lines in sysctl(3)
about the various tunables.  if we're going to stick with the current
knobs for a while yet, then we should probably have some examples somewhere
of what settings can be used to achieve various goals.


also, try these settings to keep your squid in memory:

vm.anonmin=93
vm.anonmax=100
vm.execmin=1
vm.execmax=1
vm.filemin=1
vm.filemax=1

with these values, anon pages will always be under the max (and probably
under the min as well) and the other types will always be over the max,
so all anon pages should stay in memory forever.  there may be undesirable
side-effects when the system's preference is so strongly tilted, though.

-Chuck