Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4142272ybe; Mon, 16 Sep 2019 07:22:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqy03+f+MFTM3LEYpyO0LpLAYFXp4yzVS2oAg/pvELDOfYMtcTDGX2BKrXd1zC0ivxOCL6E7 X-Received: by 2002:a05:6402:17aa:: with SMTP id j10mr61431249edy.222.1568643769039; Mon, 16 Sep 2019 07:22:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568643769; cv=none; d=google.com; s=arc-20160816; b=UweKciIIDuKuBn28Mr4TxhnKUxq291Mz7RGxbGqILnk4ZUo3BM2ESGZPX535fdclvA fBd0eUw/c0L/mVn7GhrJ9SmCX8+YFTi4VAPNkYss4SWm6+WMvOfYGbJ54MRj/L24hJCR MSCmMVahZ9okGnpDDIz1oMkGrsWUSqnVdoVwSzsxshJtAfI1xdYDT8mMqRPLK+MitLS/ VV932hm+kB7XYuGSBO+9CGWqv/25/iPSFIHcGsihp6rRRDVdLlCytAq7yaDB1v4AJIcY 2eZb/4iAeQlW6maO249vRMta8iiWIq4For6/jnM2KNSIYwe9+Lyj5aroLoQ2zGuqHjmp 8hlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=bhoVmmDovxHTJG57bJRfUjaLX1LUFcmJGyopuETtuLM=; b=OhGhDE0LOPNe2HXO7Byv6TTFIO7+8Oidp4W9U8lpRiuoF6k7UKXZwUWs+zjLmq6AoX qNM6s1DjbBBEErZz3QMAnor5lpsE1JazxIEZ6XVxjCDUSUzDOs7Fgopga/VgkuJ1+yTw O77C23Z3Lz5K2hWOxSSNpRt+/0CFO+eBxEuB0EzV9eq7sjFeKbGaQSKQm/ANdJ2BRh7d YYAgKK221+k5BJ53d9G/F4gweLDww1Q/oG7aVTa9lnTT4GYGRRl7aR2HJuQXa1L7NUEC Lc8riuXj2Q9zIAURps4VI8KZTkSDTzhGuywsmoRMfsyYWDTlBabjGOcCPE6QZYun4uLZ lDDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y16si16792862eje.248.2019.09.16.07.22.14; Mon, 16 Sep 2019 07:22:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388458AbfIPOU6 (ORCPT + 99 others); Mon, 16 Sep 2019 10:20:58 -0400 Received: from out30-57.freemail.mail.aliyun.com ([115.124.30.57]:45538 "EHLO out30-57.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388421AbfIPOU5 (ORCPT ); Mon, 16 Sep 2019 10:20:57 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01f04391;MF=xiaoguang.wang@linux.alibaba.com;NM=1;PH=DS;RN=2;SR=0;TI=SMTPD_---0TcWjSlV_1568643654; Received: from 30.8.168.199(mailfrom:xiaoguang.wang@linux.alibaba.com fp:SMTPD_---0TcWjSlV_1568643654) by smtp.aliyun-inc.com(127.0.0.1); Mon, 16 Sep 2019 22:20:55 +0800 Subject: Re: [PATCH 1/2] jbd2: add new tracepoint jbd2_sleep_on_shadow To: "Theodore Y. Ts'o" Cc: linux-ext4@vger.kernel.org References: <20190902145442.1921-1-xiaoguang.wang@linux.alibaba.com> <20190907162145.GC23683@mit.edu> <5d96e18f-9610-208f-6db3-6a7b6a112400@linux.alibaba.com> <20190911135707.GC2740@mit.edu> From: Xiaoguang Wang Message-ID: <7afa6bc5-71c1-ba8e-5d0b-ea3afc02cd84@linux.alibaba.com> Date: Mon, 16 Sep 2019 22:20:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20190911135707.GC2740@mit.edu> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org hi, > On Wed, Sep 11, 2019 at 02:52:51PM +0800, Xiaoguang Wang wrote: >>> I think maybe it might be better to use units of microseconds and then >>> change sleep to usleep so the units are clear? This is a spinlock, so >>> it should be quick. >> >> Sorry, I may not quite understand you, do you mean that milliseconds is not precise, so >> should use microseconds? For these two patches, they do not use usleep or msleep to do >> real sleep work, they just record the duration which process takes to wait bh_shadow flag >> to be cleared or transaction to be unlocked. > > Apologies, I should have been clear enough. Yes, my concern that > milliseconds might not be fine-grained enough. The sample results > which you showed had values of 2ms, 1ms, and 0ms. And the single 0ms > result in particular raised the concern that we should use a > microseconds instead of milliseconds. > > In fact, instead of "sleep", maybe "latency(us)" or "latency(ms)" > would be a better label? OK, I'll update a v2, thanks. Regards, Xiaoguang Wang > > Regards, > > - Ted >