lkml.org 
[lkml]   [2006]   [Mar]   [29]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateWed, 29 Mar 2006 13:13:14 +0400
FromKirill Korotaev <>
SubjectRe: [Devel] Re: [RFC] Virtualization steps
Sam,

>> Why do you think it can not be measured? It either can be, or it is too 
>> low to be measured reliably (a fraction of a per cent or so).> > Well, for instance the fair CPU scheduling overhead is so tiny it may as
> well not be there in the VServer patch.  It's just a per-vserver TBF
> that feeds back into the priority (and hence timeslice length) of the
> process.  ie, you get "CPU tokens" which deplete as processes in your
> vserver run and you either get a boost or a penalty depending on the
> level of the tokens in the bucket.  This doesn't provide guarantees, but
> works well for many typical workloads.
I wonder what is the value of it if it doesn't do guarantees or QoS?
In our experiments with it we failed to observe any fairness. So I 
suppose the only goal of this is too make sure that maliscuios user want 
consume all the CPU power, right?

> How does your fair scheduler work?  Do you just keep a runqueue for each
> vps?
we keep num_online_cpus runqueues per VPS.
Fairs scheduler is some kind of SFQ like algorithm which selects VPS to 
be scheduled, than standart linux scheduler selects a process in a VPS 
runqueues to run.

> To be honest, I've never needed to determine whether its overhead is 1%
> or 0.01%, it would just be a meaningless benchmark anyway :-).  I know
> it's "good enough for me".
Sure! We feel the same, but people like numbers :)

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

\
 
 \ /
  Last update: 2006-03-29 11:15    [from the cache]
©2003-2008