Re: [Devel] Re: [RFC] Virtualization steps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux