From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Core parking feature enable Date: Mon, 05 Mar 2012 21:50:25 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Haitao Shan , Keir Fraser Cc: "Liu, Jinsong" , Shaohua Li , xen-devel , Jan Beulich , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org Sorry, yes, I also had missed the ACPI interaction. On 05/03/2012 21:27, "Haitao Shan" wrote: > Thanks, Keir. We did create new hypercalls. > But for new interface(mentioned in my previous mail), I mean the > mechanisms for kernel to notify user-space for core parking decision. > This does *not* exist in kernel. If we add it specifically for Xen, I > don't think kernel people would buy-in that. > = > Shan Haitao > = > 2012/3/2 Keir Fraser : >> On 02/03/2012 09:42, "Haitao Shan" wrote: >> = >>> I would really doubt the need to create a new interface of receiving >>> ACPI event and sending to user land (other than existing native >>> kernel) specifically for Xen. What's the benefit and why kernel people >>> should buy-in that? >>> Core parking is a platform feature, not virtualization feature. >>> Naturally following native approach is the most efficient. Why do you >>> want to create yet another interface for Xen to do that? >> = >> While I sympathise with your position rather more than Jan does, the fac= t is >> that it's *you* who are suggesting yet-another-Xen-interface. Whereas do= ing >> it in userspace requires only existing hypercalls I believe. >> = >> =A0-- Keir >> = >>> Shan Haitao >>> = >>> 2012/3/1 Jan Beulich : >>>>>>> On 01.03.12 at 15:31, "Liu, Jinsong" wrote: >>>>> Jan Beulich wrote: >>>>>>>>> On 01.03.12 at 12:14, "Liu, Jinsong" wrot= e: >>>>>>> Unfortunately, yes, though cumbersome is not basic reason user space >>>>>>> approach is not preferred. Core parking is a power management staff, >>>>>>> based on dynamic physical details like cpu topologies and maps owned >>>>>>> by hypervisor. It's natural to implement >>>>>> = >>>>>> CPU topology is available to user space, and as far as I recall your >>>>>> hypervisor patch didn't really manipulate any maps - all it did was >>>>>> pick what CPU to bring up/down, and then carry out that decision. >>>>> = >>>>> No. threads_per_core and cores_per_socket exposed to userspace is >>>>> pointless >>>>> to us (and, it's questionable need fixup). >>>> = >>>> Sure this would be insufficient. But what do you think did >>>> XEN_SYSCTL_topologyinfo get added for? >>>> = >>>>> Core parking depends on following physical info (no matter where it >>>>> implement): >>>>> 1. cpu_online_map; >>>>> 2. cpu_present_map; >>>>> 3. cpu_core_mask; >>>>> 4. cpu_sibling_mask; >>>>> all of them are *dynamic*, especially, 3/4 are varied per cpu and per >>>>> online/offline ops. >>>> = >>>> Afaict all of these can be reconstructed using (mostly sysctl) >>>> hypercalls. >>>> = >>>> Jan >>>> = >>>> = >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org >>>> http://lists.xen.org/xen-devel >> = >> =