>>>>> On Mon, 04 Jul 2005 10:12:32 +0900,
	"KAMADA Ken'ichi" <kamada@nanohz.org> said:

> As far as I read the paper, it is not the source of this problem
> that the identical code shares the cache (here, shares == lives in
> the cache as one instance).

>>>>> On Mon, 04 Jul 2005 11:18:01 -0400,
	Michael Richardson <mcr@sandelman.ottawa.on.ca> said:

>   No, it is due to the fact that they are sharing the cache at all.
>   The process doing the cryptographic operations reveals whether it is
> doing *2 or +1 operations by the pattern of memory accesses it does. 

>   The spying process is noticing when the pattern by the fact that it's
> accesses to memory are slowed in different fashions by the need to fill
> the cache for the cryptographic process.

Hmm, I see. Thanks.

>   Read the paper.

Yeah. ;-)

>   My suggestion: provide a system call that grabs the "big lock" and
> prevents SMP for the duration of the call. We'd need a capability bit,
> since we might not want to restrict this to root.

Also, ideally our scheduler should know the virtual processors which are
sharing same cache...
--
soda