dirty highmem calculation sysctl name (Was: [PATCH 1/1] mm: add dirty_highmem option)

[Bron Gondwana <brong@fastmail.fm>]

On Mon, Nov 26, 2007 at 09:53:15PM -0800, Andrew Morton wrote:
> On Tue, 27 Nov 2007 16:24:24 +1100 "Bron Gondwana" <brong@fastmail.fm> wrote:
> 
> > On Mon, 26 Nov 2007 20:54:28 -0800, "Andrew Morton" <akpm@linux-foundation.org> said:
> > > On Thu, 22 Nov 2007 14:42:04 +1100 Bron Gondwana <brong@fastmail.fm>
> > > wrote:
> > > 
> > > >  /*
> > > > + * free highmem will not be subtracted from the total free memory
> > > > + * for calculating free ratios if vm_dirty_highmem is true
> > > > + */
> > > > +int vm_dirty_highmem;
> > > 
> > > One would expect that setting dirty_highmem to true would cause highmem
> > > to
> > > be accounted in dirty-memory calculations.  However with this change
> > > reality is in fact the inverse of that.
> > > 
> > > So how about this?
> > 
> > Actually, I'm confused now.  Maybe I chose a bad name to begin with.
> > Does it mean "I am allowed to dirty high memory" or "my high memory
> > will be dirty if this is on"?
> 
> But we're always allowed to dirty highmem - there'd be no point in having
> it otherwise.  Hence the term dirty_highmem is confusing.
> 
> umm, really you want
> /proc/sys/vm/dont-account-highmem-in-dirty-memory-calculations, only
> shorter.
> 
> Do you agree?

I still read dirty_highmem as:

/proc/sys/vm/do-account-highmem-in-dirty-memory-calculations

... so we're still talking one negative apart!
 
> If so, then it's still not a very pleasing interface - setting something to
> "true" to disable a particular piece of kernel behaviour implies a single
> negation which we don't really need.

Well, the particular piece of kernel behaviour is already a negative:

 "decrease the amount of memory allowed to get dirty so we never dirty
  more than a percentage of available lowmem"

So what this flag is saying is:

 "DON'T decrease the amount of memory allowed to get dirty down to just
  the lowmem - dirty a percentage of total available including highmem"

As Linus said - the alternative of allowing more than 100% of lowmem
to be dirty is just plain too wierd, hence this approach of allowing
an option to turn off the new restriction that appeared since 2.6.16.

> It would be simpler to have
> /proc/sys/vm/do-account-highmem-in-dirty-memory-calculations,
> defaulting to "true" - this has no negations.

No, that's not true.  The whole point is that between 2.6.16 and
2.6.20 the kernel behaviour changed.  It currently doesn't count
highmem in dirty memory calculations, which is why the memory pressure
appears to be so great when actually there's still 4Gb of unused
memory in the box.

/proc/sys/vm/do-account-highmem-in-dirty-memory-calculations would
default to "false" to get the current behaviour post-2.6.16 kernels.

Setting a flag to make it true would stop the kernel subtracting 
highmem from the available count, giving the "old" behaviour of
allowing a percentage of all the memory in the system to be dirty
before forcing writeback.

> So... how about /proc/sys/vm/, umm.
> 
> <looks at inbox, brain explodes>
> 
> OK, I give up.  Please see if you can think of something less confusing
> which involves no negations?

I've spent a while thinking about this, and looking at the code.

I think this might be slightly clearer:


/proc/sys/vm/highmem_is_dirtyable - defaults to false


Here's how it would look in the code:

static unsigned long determine_dirtyable_memory(void)
{
        unsigned long x;

        x = global_page_state(NR_FREE_PAGES)
                + global_page_state(NR_INACTIVE)
                + global_page_state(NR_ACTIVE);

        if (!vm_highmem_is_dirtyable)
                x -= highmem_dirtyable_memory(x);

        return x + 1; /* Ensure that we never return 0 */
}


I think that's very clear.

"Unless highmem is dirtyable, subtract the otherwise dirtyable
 pages from the total dirtyable memory count if they are in
 highmem"

Or without negatives:

"If highmem is dirtyable then include highmem pages in the
 total dirtyable memory count"

Unfortunately this isn't expressed without negatives in the
code because it's easier (I presume without looking at all the
different zones on a cruddy piece of old i386) to add up the 
total and remove the pages in the HIGHMEM zone than to add up
all the non-HIGHMEM zones separately.


Does that suit you?  Does my explaination make sense?

Would you like me to re-submit the patch based on this?  I'm
certainly not happy with dirty_highmem as it is now in mm
because it looks backwards and unclear to me.

Bron.