Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758206AbaLKO4q (ORCPT ); Thu, 11 Dec 2014 09:56:46 -0500 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:39853 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753098AbaLKO4o (ORCPT ); Thu, 11 Dec 2014 09:56:44 -0500 Message-ID: <5489B07E.9000200@fb.com> Date: Thu, 11 Dec 2014 09:55:58 -0500 From: Josef Bacik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Mike Galbraith CC: , , , , , Subject: Re: [PATCH] sched/fair: change where we report sched stats References: <1418149315-30173-1-git-send-email-jbacik@fb.com> <1418192604.5312.28.camel@marge.simpson.net> <5488BFC5.3080001@fb.com> <1418268856.5263.46.camel@marge.simpson.net> In-Reply-To: <1418268856.5263.46.camel@marge.simpson.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.16.4] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2014-12-11_03:2014-12-11,2014-12-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=142.157825103555 compositescore=0.140620555742602 urlsuspect_oldscore=0.140620555742602 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=2524143 rbsscore=0.140620555742602 spamscore=0 recipient_to_sender_domain_totalscore=8 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1412110149 X-FB-Internal: deliver Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/10/2014 10:34 PM, Mike Galbraith wrote: > On Wed, 2014-12-10 at 16:48 -0500, Josef Bacik wrote: >> On 12/10/2014 01:23 AM, Mike Galbraith wrote: >>> On Tue, 2014-12-09 at 13:21 -0500, Josef Bacik wrote: >>> >>>> This patch moves stat stuff to after the schedule, right as we are waking up, >>> >>> But sleep/block ends when the task is awakened/enqueued, not when it >>> gets the CPU. You're adding scheduling latency, breaking accounting. >>> >> >> Yes I'm aware of that. I don't care if the delay time is slightly >> higher than normal, I care about knowing exactly why we were sleeping to >> begin with. I suppose I could leave the accounting part where it is and >> then just fire the tracepoint when it's put on the CPU so we get the >> best of both worlds, but honestly I don't feel like adding the extra >> scheduling latency into the accounting is that big of a deal. Thanks, > > I think sleep/iowait should remain what they are, sleep/iowait end at > wakeup. I don't think waker trace is useless either for that matter. > Who/when ends a sleep period is just as much a part of the picture as > what triggered that sleep. Waker scheduling latency, thumb twiddling > etc. extend sleep. > Ok I'll re-roll with the stats themselves not changed. We can get the waker other ways, but if we're wanting to see how long we were asleep we are probably going to want to know why. > Shrug, maintainer call. I don't recall ever having any difficulty > determining why a task went to sleep, so don't get it. > How did you do it? I had one latency spike in a 90 minute test that runs across 30 boxes that could have been caused by anything, so if there is a way I could have easily found that without moving these tracepoints around I'd love to hear it. Thanks, Josef -- 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/