Received: by 10.192.165.148 with SMTP id m20csp4858926imm; Tue, 24 Apr 2018 09:29:42 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq+oyNineDSTu5ymm/vJNr6lYzQeX3Dr9/2tuszoUL6bje0sPyrKpHXSBSfA+68sIiNmC3b X-Received: by 2002:a17:902:d88a:: with SMTP id b10-v6mr3422511plz.81.1524587382351; Tue, 24 Apr 2018 09:29:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524587382; cv=none; d=google.com; s=arc-20160816; b=TW5a9X4UGx58ehGoZiGPV5VgbXpUTJUM1ds6qxPR3Idk4WmjSwGV9dq49A4mMRWHuf lR2QI04t30wx047GTJ+KO4XhWtNNX56dGJNeujPMWc3lJznGh1jA+uX0nOp0dR2Fst/m r5GFwHNA4Nwwg2LcL/qBP8DX1JRns5CwmR5Ui69YTxA9z6xRVh4ugoE1mUiVkqIgBq/T Bvt3rRNJ9X+vKL1PWTVMRW98mBU1Dcgnlw2iNd2dpjVHhqBjc70I3UBBvgVynkPAulnY cDJhStUb2CACnENJjxqf+wO9PHgvItbZ8mAizBcskLKuyhhX5iuUye4PYdEJ1Re3EB41 8edQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=ymw7kMxYr//BIDumhtzg5bQNiBjdzMPhl7kPPVHoics=; b=yDmEVAwYqqjNybrnb7cmUMwk1LXRmzHyCIlFy/rNwJfF7eSrdfMSYbFJkFjv6l8UC+ lXp9bZTmkOGikMwvCsQPBArB02ymNrj7XTs41yC18gyX0AGE61M/un3F6PYvurRJcaR+ SLiURDm4tQasImNMWxp3F5znUkLjR3ATz2DFzYFczUlyRHlQRADkxldIXteB2ttK37Ah LG95uSfGlHFYqEE4AAL0ff0UE00bpKSm3fSyhNwtkR7SyLoCCiqCXEr02VdrAkrvsoCD e2Opg1eHSMlUmu05onKrDsJYeRbyfXPIyBKkT3bL+pRffHx6xu6vL650WPNn6TL6XbBu Q7IQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z9-v6si2182634pll.423.2018.04.24.09.29.27; Tue, 24 Apr 2018 09:29:42 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752593AbeDXQ2B (ORCPT + 99 others); Tue, 24 Apr 2018 12:28:01 -0400 Received: from mga06.intel.com ([134.134.136.31]:16170 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751053AbeDXQ17 (ORCPT ); Tue, 24 Apr 2018 12:27:59 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2018 09:27:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,323,1520924400"; d="scan'208";a="48731752" Received: from clanggaa-mobl.ger.corp.intel.com (HELO localhost) ([10.249.254.59]) by fmsmga004.fm.intel.com with ESMTP; 24 Apr 2018 09:27:53 -0700 Date: Tue, 24 Apr 2018 19:27:52 +0300 From: Jarkko Sakkinen To: Nayna Jain Cc: linux-integrity@vger.kernel.org, zohar@linux.vnet.ibm.com, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, peterhuewe@gmx.de, tpmdd@selhorst.net, jgunthorpe@obsidianresearch.com, patrickc@us.ibm.com Subject: Re: [PATCH v2 1/2] tpm: reduce poll sleep time in tpm_transmit() Message-ID: <20180424162752.GC5119@linux.intel.com> References: <20180417131246.434-1-nayna@linux.vnet.ibm.com> <20180417131246.434-2-nayna@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180417131246.434-2-nayna@linux.vnet.ibm.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 17, 2018 at 09:12:45AM -0400, Nayna Jain wrote: > The TPM polling code in tpm_transmit sleeps in each loop iteration for > 5 msecs. However, the TPM might return earlier, and thus waiting for > 5 msecs adds an unnecessary delay. This patch reduces the polling sleep > time in tpm_transmit() from 5 msecs to 1 msecs. I'm not sure what TPM returning earlier has to do with this. TPM probably never returns exactly in the spec defined timeout/duration. I just don't understand reasoning in this paragraph. > Additionally, this patch renames TPM_POLL_SLEEP and moves it to tpm.h as > an enum value. > > After this change, performance on a TPM 1.2 with an 8 byte burstcount > for 1000 extends improved from ~14 sec to ~10.7 sec. You cannot give absolute numbers without a context (platform, software). > Signed-off-by: Nayna Jain /Jarkko