Re: [Engine-devel] [vdsm] CPU Overcommit Feature

On Wed, Dec 19, 2012 at 09:53:15AM -0500, Doron Fediuck wrote: > > ----- Original Message ----- >> From: "Dan Kenigsberg" <danken(a)redhat.com&gt; >> To: "Greg Padgett" <gpadgett(a)redhat.com&gt; >> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, vdsm-devel(a)fedorahosted.org >> Sent: Wednesday, December 19, 2012 3:59:11 PM >> Subject: Re: [Engine-devel] CPU Overcommit Feature >> >> On Mon, Dec 17, 2012 at 09:37:57AM -0500, Greg Padgett wrote: >>> Hi, >>> >>> I've been working on a feature to allow CPU Overcommitment of hosts >>> in a cluster. This first stage allows the engine to consider host >>> cpu threads as cores for the purposes of VM resource allocation. >>> >>> This wiki page has further details, your comments are welcome! >>> http://www.ovirt.org/Features/cpu_overcommit >> >> I've commented about the vdsm/engine API on >> http://gerrit.ovirt.org/#/c/10144/ but it is probably better to >> reiterate it here. >> >> The suggested API is tightly coupled with an ugly hack we pushed to >> vdsm >> in order not to solve the issue properly on the first strike. >> >> If we had not have report_host_threads_as_cores, I think we'd have a >> simpler API reporting only cpuThreads and cpuCores; with no funny >> boolean flags. >> >> Let us strive to that position as much as we can. >> >> How about asking whoever used report_host_threads_as_cores to unset >> it >> once they install Engine 3.2 ? I think that these are very few >> people, >> that would not mind this very much. >> >> If this is impossible, I'd add a cpuCores2, always reporting the true >> number, to be used by new Engines. We may even report it only on the >> very few cases of report_host_threads_as_cores being set. >> >> Dan. > > Hi Dan, > Thanks for the review. > > I agree simply reporting cores and threads would be the right solution. > However, when you have hyperthreading turned off you get cores=threads. > This is the same situation you have when hyperthreading turned on, and > someone used the vdsm configuration of reporting threads as cores. > > So the engine won't know the real status of the host. This is not surprising, as report_host_threads_as_cores means in blunt English "lie to Engine about the number of cores". The newly suggested flag says "don't believe what I said in cpuCores, since I'm lying". Next thing we'd have is another flag saying that the former flag was a lie, and cpuCores is actually trustworthy. Instead of dancing this dance, I suggest to stop lying. report_host_threads_as_cores was a hack to assist a older Engine versions. Engine users that needed it had to set it out-of-band on their hosts. Now if they upgrade their Engine, they can -- as easily -- reset that value. If they forget, nothing devastating happens beyond Engine assuming that hyperthreading is off. Please consider this suggestion. I find it the simplest for all involved parties.

Dan. > We need to be > able to tell the difference. So this moves us to cpuCores2 suggestion. > This is one possibility (cpuRealCores?), and the alternative is an > indication of vdsm config (true/false) which may be removed in the future. > I suspect over time cpu and cpu2 will confuse people. > > So I'd suggest having the boolean and removing it along with the vdsm > configuration in the next ovirt version. _______________________________________________ vdsm-devel mailing list vdsm-devel(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel