RE: Cache coherency... and locking

Linda Walsh (law@sgi.com)
Fri, 21 Jul 2000 09:21:47 -0700

So it sounds like the safest way to do things is to use a spinlock on a per-process
basis -- which should almost never fail resulting in mininal overhead. If I want
to globally turn audit on/off, I need to lock the task struct and walk through
it setting audit on/off flags to allowed values. The thing that is a pain is
that the auditmask is 256 bytes long or a full cache line. Checking an extra
byte would require two cache loads if auditing is turned on. Maybe it would
be better just to reserve the sign bit of first audit mask as the on/off flag --
if I can ensure the entire audit mask is in 1 32-byte cache line should minimize
performance hit. Yes? I'm assuming the fastest portable way to check that 1 bit
would be (val<0) -- which on Intel...not sure how it handles the sign compare for
a 64 bit int. Does it do the smart thing and only look at the high bit of the
high word of the high dword and just not mess with the rest of the quantity?
I suppose we could use 4x32 bit words for an audit mask rather than 2x64 -- speeding
things up for the 32 bit case. If I structure it as a default that can be
overriden on a per-platform basis then native 64-bit machines could change the
test macros to be optimal for their platform.

-l

--
Linda A Walsh                    | Trust Technology, Core Linux, SGI
law@sgi.com                      | Voice: (650) 933-5338                        




> -----Original Message-----
> From: Oliver Xymoron [mailto:oxymoron@waste.org]
> Sent: Friday, July 21, 2000 8:50 AM
> To: Linda Walsh
> Cc: Keith Owens; linux-kernel@vger.rutgers.edu
> Subject: RE: Cache coherency... and locking 
> 
> 
> On Fri, 21 Jul 2000, Oliver Xymoron wrote:
> 
> > > 	You say we are 'assuming' writes show up in the order performed,
> > > that implies it may not be true?
> > 
> > True for all the processors we're currently working with. Linus talks
> > about assuming a 'sane architecture' as the common core and making ports
> > minimal variations from that. Currently write ordering is one of those
> > things considered sane. 
> 
> Retraction time - Manfred's right, we don't generally assume write
> ordering on SMP. Writes remain ordered on single processors (ie reads
> never speculate ahead of writes) but that's fairly obviously the only sane
> way to go. x86 is strongly ordered but other systems and things like PCI
> bus are not necessarily.
> 
> It's best not to think about subtle things like causality models at 2am.
> 
> --
>  "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 
> 
> 


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