From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_MUTT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95CC7C48BD3 for ; Wed, 26 Jun 2019 14:54:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6EDB12063F for ; Wed, 26 Jun 2019 14:54:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="NUkq18lO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727959AbfFZOx6 (ORCPT ); Wed, 26 Jun 2019 10:53:58 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:60106 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726948AbfFZOx5 (ORCPT ); Wed, 26 Jun 2019 10:53:57 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5QEn0u0115886; Wed, 26 Jun 2019 14:52:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2018-07-02; bh=O8gsLAnKvEJnxFFzMobAjm8cu3fNADVN1xEFWlBOGbk=; b=NUkq18lOFFDWIv9CTLHNhjC+dTnEhg5+Sp2EPg1lNCYslPeZx79gEYt6+PICxltUHb7x 4OW7B5GmqcMkuDWq13q9q0VlmCnrsv6KVUfOy6nmNo40x/ImzH52Iwp1jUQ/p0IlaEuU Q/mTqg6aRbc5nDqUcfrFWrc1hngRRhNpUzWDZ9LOBQhVZb4C/5p55lqB4fSvmh2lu4Rs CStecoPZ+OftnKBUbXPFDpJ+yCH4lCdMJi/XsAi8LeQPvKA/HJIexEIz0t+m5s2ErXyz 9uJg0qq9NpBrPB+ppBig1llbzOHuXsqEDV6KhekjuyjOcfCjRe1DTuk12NwzkJpoVTb/ IQ== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2t9cyqjsa5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Jun 2019 14:52:58 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5QEqfSM175391; Wed, 26 Jun 2019 14:52:58 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 2tat7cv8ys-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 26 Jun 2019 14:52:58 +0000 Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x5QEqnwe005115; Wed, 26 Jun 2019 14:52:49 GMT Received: from char.us.oracle.com (/10.152.32.25) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Jun 2019 07:52:49 -0700 Received: by char.us.oracle.com (Postfix, from userid 1000) id 6B9A06A0150; Wed, 26 Jun 2019 10:54:13 -0400 (EDT) Date: Wed, 26 Jun 2019 10:54:13 -0400 From: Konrad Rzeszutek Wilk To: Thomas Gleixner , Boris Ostrovsky , Ankur Arora , Joao Martins Cc: Wanpeng Li , Peter Zijlstra , Paolo Bonzini , Radim Krcmar , Marcelo Tosatti , KarimAllah , LKML , kvm Subject: Re: cputime takes cstate into consideration Message-ID: <20190626145413.GE6753@char.us.oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9299 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906260176 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9299 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906260175 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, Jun 26, 2019 at 12:33:30PM +0200, Thomas Gleixner wrote: > On Wed, 26 Jun 2019, Wanpeng Li wrote: > > After exposing mwait/monitor into kvm guest, the guest can make > > physical cpu enter deeper cstate through mwait instruction, however, > > the top command on host still observe 100% cpu utilization since qemu > > process is running even though guest who has the power management > > capability executes mwait. Actually we can observe the physical cpu > > has already enter deeper cstate by powertop on host. Could we take > > cstate into consideration when accounting cputime etc? > > If MWAIT can be used inside the guest then the host cannot distinguish > between execution and stuck in mwait. > > It'd need to poll the power monitoring MSRs on every occasion where the > accounting happens. > > This completely falls apart when you have zero exit guest. (think > NOHZ_FULL). Then you'd have to bring the guest out with an IPI to access > the per CPU MSRs. > > I assume a lot of people will be happy about all that :) There were some ideas that Ankur (CC-ed) mentioned to me of using the perf counters (in the host) to sample the guest and construct a better accounting idea of what the guest does. That way the dashboard from the host would not show 100% CPU utilization. But the patches that Marcelo posted (" cpuidle-haltpoll driver") in "solves" the problem for Linux. That is the guest wants awesome latency and one way was to expose MWAIT to the guest, or just tweak the guest to do the idling a bit different. Marcelo patches are all good for Linux, but Windows is still an issue. Ankur, would you be OK sharing some of your ideas? > > Thanks, > > tglx >