On 17.01.2018 18:15, Mimi Zohar wrote:
On Mon, 2018-01-15 at 17:30 -0500, Mimi Zohar wrote:
What would be a better implementation? No delay and simply retry for
five seconds?
What TPMs are you using for your tests? At least for the TPMs that I
have available for my tests (with a FIFO size of ~256 bytes) I would not
expect any wait states for extend commands.
The TPM burstcount is 32. Unfortunately, with this patch set the
performance on the pi is worse than without it. Without this patch
set we're seeing ~14 secs for a thousand measurements vs. either ~38s
or ~23s, depending on the wait sleep length introduced in patch 8/9.
From my response, it might not have been clear that with all of the
patches, except this one 8/9 calling tpm_msleep(), the performance is
equivalent to without any of the patches. With this patch set, but
with or without the call to tpm_msleep(), it loops 2 or 3 times.
Thanks for your tests. I haven't yet done such extensive performance
tests for those changes. But I've got some performance tests that I
still want to run to see what performance impact I can measure with my TPMs.
It seems clear to me that for optimum performance there shouldn't be any
sleeps, at least not for the first few retries. If I use a time limit
instead of counting the number of retries, are sleeps necessary at all?
The SPI bus is locked anyway, so nothing else can use it while we are
sleeping. The SPI transfers should slow us down sufficiently, so that we
are not consuming 100% of CPU time. And in the common cases (at least
those that we know) the wait states seem to clear up pretty quickly.
If there are no objections, I'll rewrite the patch in such a way (time
limit of several seconds, no sleeps). Maybe it is also worth trying to
see what performance can be gained by removing more sleeps, in
wait_for_tpm_stat and elsewhere. Perhaps the first millisecond(s) or so
should always be busy waiting, and sleeps should only come afterwards.
Alexander
