From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752785AbcHOJ6K (ORCPT ); Mon, 15 Aug 2016 05:58:10 -0400 Received: from outbound-smtp09.blacknight.com ([46.22.139.14]:49026 "EHLO outbound-smtp09.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752073AbcHOJ6J (ORCPT ); Mon, 15 Aug 2016 05:58:09 -0400 Date: Mon, 15 Aug 2016 10:58:04 +0100 From: Mel Gorman To: Stanislaw Gruszka Cc: Giovanni Gherdovich , Ingo Molnar , Ingo Molnar , Peter Zijlstra , Mike Galbraith , linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] sched/cputime: Mitigate performance regression in times()/clock_gettime() Message-ID: <20160815095804.GF8119@techsingularity.net> References: <1470385316-15027-1-git-send-email-ggherdovich@suse.cz> <1470385316-15027-2-git-send-email-ggherdovich@suse.cz> <20160810112641.GA30126@gmail.com> <20160812121010.GA30199@redhat.com> <1471247345.1776.2.camel@suse.cz> <20160815083349.GE8119@techsingularity.net> <20160815091900.GA19741@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20160815091900.GA19741@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 15, 2016 at 11:19:01AM +0200, Stanislaw Gruszka wrote: > > Is this really equivalent though? It updates one task instead of all > > tasks in the group and there is no guarantee that tsk == current. > > Oh, my intention was to update runtime on current. > Ok, so minimally that would need addressing. However, then I would worry that two tasks in a group calling the function at the same time would see different results because each of them updated a different task. Such a situation is inherently race-prone anyway but it's a large enough functional difference to be worth calling out. Minimally, I don't think such a patch is a replacement for Giovanni's which is functionally equivalent to the current code but could be layered on top if it is proven to be ok. > > Glancing at it, it should monotonically increase but it looks like it > > would calculate stale data. > > Yes, until the next tick on a CPU, the patch does not count partial > runtime of thread running on that CPU. However that was the behaviour > before commit d670ec13178d0 - that how old thread_group_sched_runtime() > function worked: > Sure, but does this patch not reintroduce the "SMP wobble" and the problem of "the diff of 'process' should always be >= the diff of 'thread'" ? -- Mel Gorman SUSE Labs