Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1731781 > unrolled thread
| Started by | Ken Goldman <kgold@linux.vnet.ibm.com> |
|---|---|
| First post | 2017-09-13 21:00 +0200 |
| Last post | 2017-09-13 21:10 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [tpmdd-devel] [PATCH v2 1/4] tpm: ignore burstcount to improve tpm_tis send() performance. Ken Goldman <kgold@linux.vnet.ibm.com> - 2017-09-13 21:00 +0200
Re: [tpmdd-devel] [PATCH v2 1/4] tpm: ignore burstcount to improve tpm_tis send() performance. Peter Huewe <peterhuewe@gmx.de> - 2017-09-13 21:10 +0200
| From | Ken Goldman <kgold@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-09-13 21:00 +0200 |
| Subject | Re: [tpmdd-devel] [PATCH v2 1/4] tpm: ignore burstcount to improve tpm_tis send() performance. |
| Message-ID | <upl3b-2DF-1@gated-at.bofh.it> |
On 9/6/2017 12:12 PM, Jason Gunthorpe wrote: > > The problem with this approach is that the TPM could totally block > the CPU for very long periods of time. > > It seems very risky to enable.. > How would you characterize "very long"? The TPM vendors confirm that they empty the FIFO at internal speeds that are comparable to the bus speed. Thus, any stall will be sub-usec. Is that an issue? In addition, new TPMs have ever larger FIFO's, making stalls less likely going forward.
[toc] | [next] | [standalone]
| From | Peter Huewe <peterhuewe@gmx.de> |
|---|---|
| Date | 2017-09-13 21:10 +0200 |
| Subject | Re: [tpmdd-devel] [PATCH v2 1/4] tpm: ignore burstcount to improve tpm_tis send() performance. |
| Message-ID | <uplcR-2VZ-1@gated-at.bofh.it> |
| In reply to | #1731781 |
Am 13. September 2017 11:52:12 GMT-07:00 schrieb Ken Goldman <kgold@linux.vnet.ibm.com>: >On 9/6/2017 12:12 PM, Jason Gunthorpe wrote: >> >> The problem with this approach is that the TPM could totally block >> the CPU for very long periods of time. >> >> It seems very risky to enable.. >> > >How would you characterize "very long"? > >The TPM vendors confirm that they empty the FIFO at internal speeds >that >are comparable to the bus speed. Thus, any stall will be sub-usec. Is >that an issue? If the tpm does behave correctly, this is fine. If the tpm hangs for whatever reason, your machine is frozen and you will never figure out why. That's my concern there. However ddwg seems fine. > >In addition, new TPMs have ever larger FIFO's, making stalls less >likely >going forward. But also reduced the polling loops that introduce the performance penalty ;) > > >------------------------------------------------------------------------------ >Check out the vibrant tech community on one of the world's most >engaging tech sites, Slashdot.org! http://sdm.link/slashdot >_______________________________________________ >tpmdd-devel mailing list >tpmdd-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/tpmdd-devel -- Sent from my mobile
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web