On 06/28/2010 10:41 AM, Sheng Yang wrote:
Hm, the manual says (regarding clflush):
Invalidates the cache line that contains the linear address specified
with the source
operand from all levels of the processor cache hierarchy (data and
instruction). The
invalidation is broadcast throughout the cache coherence domain. If,
at any level of
the cache hierarchy, the line is inconsistent with memory (dirty) it
is written to
memory before invalidation.
So I don't think you need to queue_work_on(), instead you can work in
vcpu thread context. But better check with someone that really knows.
Yeah, I've just checked the instruction as well. For it would be boardcasted,
seems we even don't need(and can't have) a dirty bitmap. So the overhead on the
large machine should be big.
And I've calculated the times we need to execute clflush for whole guest memory. If
I calculate it right, for a 64bit guest, clflush can only cover 64 bytes one time,
so for a typical 4G guest, we would need to execute the command for 4G / 64 = 64M
times. The cycles used by clflush can be vary, suppose it would use 10 cycles each
(which sounds impossible, for involving boardcast and writeback, and not including
cache refill time for all processors), it would cost more than 0.2 seconds one time
on an 3.2Ghz machine...
Right, so clflush can't be made to work.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
