Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752168AbdHIUWk (ORCPT ); Wed, 9 Aug 2017 16:22:40 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56855 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752120AbdHIUWh (ORCPT ); Wed, 9 Aug 2017 16:22:37 -0400 Subject: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net, linux-ima-devel@lists.sourceforge.net References: <20170807114632.1339-1-nayna@linux.vnet.ibm.com> <20170808191145.kggmoczd5laiccrn@linux.intel.com> From: Ken Goldman Date: Wed, 9 Aug 2017 16:23:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170808191145.kggmoczd5laiccrn@linux.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17080920-2213-0000-0000-000002071B8A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007514; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000219; SDB=6.00899961; UDB=6.00450512; IPR=6.00680166; BA=6.00005520; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016615; XFM=3.00000015; UTC=2017-08-09 20:22:35 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17080920-2214-0000-0000-0000572A2F5E Message-Id: <819e3d38-3f16-a32b-1928-c425b763d5f8@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-09_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708090319 To: unlisted-recipients:; (no To-header on input) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 841 Lines: 22 On 8/8/2017 3:11 PM, Jarkko Sakkinen wrote: > On Mon, Aug 07, 2017 at 01:52:34PM +0200, Peter Huewe wrote: >> Imho: NACK from my side. > After these viewpoints definitive NACK from my side too... I responded to the thread comments separately. However, assuming NACK is the final response, I have a question. The problem is the 5 msec sleep between polls of burst count. In the case of one TPM with an 8 byte FIFO, a 32 byte transfer incurs 4 of these sleeps. Would another solution be to reduce the burst count poll and sleep to, e.g., 100 usec or even 10 usec? This would probably help greatly, but still not incur the wait states that triggered the NACK. My worry is that the scheduler would not be able to context switch that fast, and so we wouldn't actually see usec speed polling. Can a kernel expert offer an opinion?