Re: Summary of discussion of harvester/random locking and performance optimization

On Sat, 2004-Aug-14 11:26:51 -0400, Robert Watson wrote:
>  I observed that get_cyclecounter() is very cheap on modern
>hardware, but that on older hardware without a TSC, it's extraordinarily
>expensive.  In particular, the #ifdef code on i386 suggests that i486
>systems may not have a TSC, and insead read the system clock (ouch!).  We
>may want to investigate what approaches we can use to mitigate this,
>especially if systems like soekris boxes don't have TSC.

True.  AFAIR, the TSC was introduced with the Pentium.  The i386 is
deprecated and my impression was that 5.x would not expend much effort
in efficiently supporting the i486.  If the various low-end iA32 clones
do support the TSC, there seems little point in changing the status quo.

>  Right now, the
>API for retrieving cycle counts does not allow the caller to easily
>distinguish those two cases, and it may be we need to teach it to do that
>so that we can allow the caller to decide it doesn't want to pay the
>higher cost.

My understanding is that the intent of using get_cyclecounter() in the
entropy havesting is simply to get a number that is varying in a way
that is mostly independent of and not controlled by the caller.  In
this case, binuptime() is definitely overkill.  Rather than expand
get_cyclecounter() to understand the caller's intent, maybe the
harvesting code should use a alternative API with a cheaper-and-dirtier
non-TSC case:  read the i8254 counter value and maybe combine it
with timehands->th_offset without worrying about any locking or
other niceties - this has almost as much entropy as bintime() but
is very much cheaper.

-- 
Peter Jeremy