From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932851AbcFGLxl (ORCPT ); Tue, 7 Jun 2016 07:53:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58371 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754542AbcFGLxf (ORCPT ); Tue, 7 Jun 2016 07:53:35 -0400 Subject: Re: Fw: [PATCH v4 2/3] sched/cputime: Fix prev steal time accouting during cpu hotplug To: Wanpeng Li , "linux-kernel@vger.kernel.org" , kvm References: <1465661590-4732-1-git-send-email-wanpeng.li@hotmail.com> <15351b9b-563a-8945-5fb6-2df15107f0d6@redhat.com> Cc: Radim Krcmar , Wanpeng Li , Ingo Molnar , "Peter Zijlstra (Intel)" , Rik van Riel , Thomas Gleixner , Frederic Weisbecker From: Paolo Bonzini Message-ID: <0fd9638b-b0f7-156e-e314-bb32a4720773@redhat.com> Date: Tue, 7 Jun 2016 13:53:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 07 Jun 2016 11:53:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/06/2016 13:50, Wanpeng Li wrote: >> > I'm not sure this patch is necessary. Instead you could just revert >> > commit e9532e69b8d1. The previous patch obviously makes it unnecessary >> > to reset rq->prev_steal_time and rq->prev_steal_time_rq, and the reset >> > of rq->prev_irq_time looks like a no-op to me. > The reason why I'm not just simple revert it is that commit mentioned > "steal is smaller than rq->prev_steal_time we end up with an insane > large value which then gets added to rq->prev_steal_time, resulting in > a permanent wreckage of the accounting." With this patch, you go back to having underflow if steal is smaller than rq->prev_steal_time. The point is that it should never be smaller; it was only smaller because of the bug that you are fixing in patch 1. Thanks, Paolo Though I didn't meet such > scenario. So I just do what that commit really want to do.