On Wed, 24 November 2004 14:02:07 +0100, Herbert Poetzl wrote:
> On Wed, Nov 24, 2004 at 05:01:47PM +1300, Sam Vilain wrote:
> 
> pages to be swapped out can not easily be assigned
> to a context, this is different for pages getting
> paged in ...

Or any page-fault done for the context, for that matter.  There is no
fundamental difference between swapping in, faulting in the
recently-started openoffice, malloc&memset, ...

> > Here's a thought about an algorithm that might work.  This is all 
> > speculation without much regard to the existing implementations out
> > there, of course.  Season with grains of salt to taste.
> > 
> > Each context is assigned a target RSS and VM size.  Usage is counted a
> > la disklimits (Herbert - is this already done?), but all complex
> 
> yep, not relative as with disklimits, but absolute
> and in identical way the kernel accounts RSS and VM
> 
> > recalculation happens when somethings tries to swap something else out.
> > 
> > As well as memory totals, each context also has a score that tracks how
> > good or bad they've been with memory.  Let's call that the "Jabba"
> > value.
> > 
> > When swap displacement occurs, it is first taken from disproportionately
> > fat jabbas that are running on nearby CPUs (for NUMA).  Displacing
> > other's memory makes your context a fatter jabba too, but taking from
> > jabbas that are already fat is not as bad as taking it from a hungry
> > jabba.  When someone takes your memory, that makes you a thinner jabba.
> > 
> > This is not the same as simply a ratio of your context's memory usage to
> > the allocated amount.  Depending on the functions used to alter the
> > jabba value, it should hopefully end up measuring something more akin to
> > the amount of system memory turnover a context is inducing.  It might
> > also need something to act as a damper to pull a context's jabba nearer
> > towards the zero point during lulls of VM activity.
> > 
> > Then, if you are a fat jabba, maybe you might end up getting rescheduled
> > instead of getting more memory whenever you want it!
> 
> thought about a simpler approach, with a TB for the
> actual page-ins, so that every page-in will consume
> a token, and you get a number per interval, as usual ...

It misses a few corner-cases, but I cannot think of anything better.
More complicated approaches would miss different corner-cases, but
that's not a real advantage.

With the simple TB approach, any IO caused on behalf of a process
gets accounted.  Updatedb would be a huge offender, but that looks
more like a feature than a bug.

Jörn

-- 
Victory in war is not repetitious.
-- Sun Tzu
_______________________________________________
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver

Reply via email to