Re: Autoregulate swappiness & inactivation

[FabF]

On Thu, 2004-07-08 at 10:27, Con Kolivas wrote:
> Andrew Morton writes:
> 
> > Con Kolivas <kernel@xxxxxxxxxxx> wrote:
> >>
> >> Andrew Morton writes:
> >> 
> >> > Con Kolivas <kernel@xxxxxxxxxxx> wrote:
> >> >>
> >> >>  Ah what the heck. They can only be knocked back to where they already are.
> >> > 
> >> > hm.  You get an eGrump for sending two patchs in one email.  Surprisingly
> >> > nice numbers though.
> >> > 
> >> > How come vm_swappiness gets squared?  That's the mysterious "bias
> >> > downwards", yes?  What's the theory there?
> >> 
> >> No real world feedback mechanism is linear. As the pressure grows the 
> >> positive/negative feedback grows exponentially.
> > 
> > That takes me back.  The classic control system is PID:
> > Proportional/Integral/Derivative - they refer to the way in which the error
> > term (output-desired output) is fed back to the input:
> > 
> > Proportional: the bigger the error, the more input drive
> > 
> > Integral: feeding back a bit of the integral of the error prevents
> > permanent output skew due to non-infinite forward gain.
> > 
> > Derivative: feeding back -(rate of change) provides damping.
> > 
> > You can live without I and D - the main thing is to feed back the -error.
> > 
> > IOW: linear works just fine :)
> 
> /me hides
> 
> Umm sorry the control systems I look at are physiological and tend to be 
> exponential, so ignore me.
> 
> > Your answer didn't help me understand the design though.
> 
> Ok I'll just describe it. I should have just said that when mapped pages are 
> low the best seems to be a very low swappiness, but not zero as zero seems 
> to get bogged down easily (kswapd gets busy and basic things take longer) as 
> occasionally slipping some pages onto swap helps. Generally it's when what I 
> called the application pages (blush) get to around 75% that allowing things 
> to swap at the rate equivalent to swappiness==60 is helpful. Once the mapped 
> pages went greater than 75% the machine would start bogging down again if 
> the swappiness remained at 60. I guess I made up the maths to fill the way 
> the design worked best. Linear brought up the swappiness too easily and 
> under swap thrash made things worse. It looked nicer but didn't really 
> behave well.
> 
> >> > Please define this new term "application pages"?
> >> 
> >> errm it's fuzzy to say the least. It's the closest I can come to 
> >> representing what end users understand as "non-cached" pages.
> > 
> > Isn't that mapped pages?
> 
> I'm all ears.
> 
> >> > Those si_swapinfo() and si_meminfo() calls need to come out of there.
> >> 
> >> I'm game. I had the idea but not the skill. Anyone wanna help me with that?
> > 
> > Need to work out what cen be removed first.  The freeswap/totalswap can go.
> >  That leaves us needing what?  totalram and freeram.  If the algorithm can
> > be flipped over to use nr_mapped, we'd be looking good.
> 
> Ok. I need some time to clean up this mess and try and figure out what to do 
> then.
Con,
	What's interesting is try_to_free_pages comment :

" the zone may be full of dirty or under-writeback pages, which this
 * caller can't do much about.  We kick pdflush and take explicit naps
in the
 * hope that some of these pages can be written.  But if the allocating
task..."

	I mean do we have high activity profile of that side of the kernel when
bringing up some big application to life ?
	Does work consist here in 50% out, 50% in (time) ? Your anticipation
algorithm can help the "in" side but maybe we can optimize yet the "out"
side.btw, I'm surprised to see autoswappiness so far in fx tree:

page_reclaim
	try_to_free_pages
		shrink_caches
			shrink_zone
				refill_inactive_zone
					auto_swap calculation


IOW, does such parameter could not involve more decisions ?

Regards,
FabF

> 
> Con
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/