Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752817AbbF2TJM (ORCPT ); Mon, 29 Jun 2015 15:09:12 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:33326 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751849AbbF2TJF convert rfc822-to-8bit (ORCPT ); Mon, 29 Jun 2015 15:09:05 -0400 MIME-Version: 1.0 In-Reply-To: <1435604090.21928.19.camel@j-VirtualBox> References: <1434099316-29749-1-git-send-email-fredrik.markstrom@gmail.com> <1434099316-29749-2-git-send-email-fredrik.markstrom@gmail.com> <1434104217.1495.74.camel@twins> <20150612110158.GA18673@twins.programming.kicks-ass.net> <20150629145837.GE3644@twins.programming.kicks-ass.net> <1435604090.21928.19.camel@j-VirtualBox> From: =?UTF-8?Q?Fredrik_Markstr=C3=B6m?= Date: Mon, 29 Jun 2015 21:08:34 +0200 Message-ID: Subject: Re: [PATCH 1/1] cputime: Make the reported utime+stime correspond to the actual runtime. To: Jason Low Cc: Peter Zijlstra , mingo@redhat.com, linux-kernel@vger.kernel.org, Rik van Riel , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2640 Lines: 83 I don't think that is good enough. I believe the reason the max()-stuff was initially put there to make sure the returned stime and utime components are increasing monotonically. The scaling code can cause either or to decrease from one call to the other even i rtime increases. The purpose of my patch is to also make sure that the sum of utime and stime is rtime. I lost the last part of the patch in my previous email: - cputime_advance(&prev->stime, stime); - cputime_advance(&prev->utime, utime); + if (stime < prev->stime) { + stime = prev->stime; + utime = rtime - stime; + } else if (utime < prev->utime) { + utime = prev->utime; + stime = rtime - utime; + } -out: + if (prev->stime + prev->utime < rtime) { + prev->stime = stime; + prev->utime = utime; + } *ut = prev->utime; *st = prev->stime; /Fredrik On Mon, Jun 29, 2015 at 8:54 PM, Jason Low wrote: > On Mon, 2015-06-29 at 17:28 +0200, Fredrik Markström wrote: >> Hello Peter, the locking part looks good, I don't have a strong >> opinion on per task/signal lock vs global lock. >> >> But with the patch we still update prev->utime and prev->stime >> independently, which was the original problem. But maybe the locking >> and monoticity/sum issue should be addressed by two separate patches >> since they are separate bugs ? >> >> The part I'm referring to is the change below from my original patch >> (maybe without the WARN_ON:s ?): >> >> … >> - cputime_advance(&prev->stime, stime); >> - cputime_advance(&prev->utime, utime); >> + if (stime < prev->stime) { >> + stime = prev->stime; >> + utime = rtime - stime; >> + } else if (utime < prev->utime) { >> + utime = prev->utime; >> + stime = rtime - utime; >> + } >> + WARN_ON(stime < prev->stime); >> + WARN_ON(utime < prev->utime); >> + WARN_ON(stime + utime != rtime); > > How about substituting: > > prev->stime = max(prev->stime, stime); > prev->utime = max(prev->utime, utime); > > with > > if (stime > prev->stime || utime > prev->utime) { > prev->stime = stime; > prev->utime = utime; > } > > in Peter's patch? > -- /Fredrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/