Re: [RFC PATCH 0/3] generic hypercall support

[Anthony Liguori]

Gregory Haskins wrote:
> Its more of an issue of execution latency (which translates to IO
> latency, since "execution" is usually for the specific goal of doing
> some IO).  In fact, per my own design claims, I try to avoid exits like
> the plague and generally succeed at making very few of them. ;)
>
> So its not really the .4% reduction of cpu use that allures me.  Its the
> 16% reduction in latency.  Time/discussion will tell if its worth the
> trouble to use HC or just try to shave more off of PIO.  If we went that
> route, I am concerned about falling back to MMIO, but Anthony seems to
> think this is not a real issue.
>   

It's only a 16% reduction in latency if your workload is entirely 
dependent on the latency of a hypercall.  What is that workload?  I 
don't think it exists.

For a network driver, I have a hard time believing that anyone cares 
that much about 210ns of latency.  We're getting close to the cost of a 
few dozen instructions here.

Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/