lkml.org 
[lkml]   [2000]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Cache coherency... and locking
Linda Walsh wrote:
>
> No -- I meant *just* reading. A process will need to read it's audit mask
> at every audit point. The audit mask would rarely be audited.
>
> Note that in no case am I doing a 'read-modify-write'. Reads and
> writes are stricly LOAD or STORE. Now it would be convenient to
> have the audit mask structure (32 bytes) aligned directly on a
> cache boundary for optimal performance.

Do you an atomic update for these 32 bytes, or is it acceptable if the
second cpu sees the old bytes 0..7, 12..31, and the updated bytes 8..11?

A write to one aligned int or long variable is atomic (*), but you
shouldn't make assumptions about the order between multiple int/long
writes.

If you need an atomic update, then you definitively need a lock.

And: do you need a synchroneous update?

I mean: cpu1 is near the audit point, and cpu2 changes the audit mask.
Do you have to guarantee that if cpu1 is before the audit point, and
cpu2 has returned from the "change_audit" function, that then cpu1 will
see the new audit mask?

All fast cpu queue memory writes, so the window is at least several
dozend cpu ticks even on i386, and on NUMA it could be huge.


> Is there a way to guarantee
> that on X86? Does the -malign=x on the command line do that?
>

If you want to align a structure, then use

struct my_struct {
int my_val;
} __attribute__ ((__aligned__(SMP_CACHE_BYTES)));


From another mail:
> 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.

You could also use a big reader spinlock, see
linux/include/linux/brlock.h.

> The thing that is a pain is
> that the auditmask is 256 bytes long or a full cache line.

256 bits?

> I suppose we could use 4x32 bit words for an audit mask rather than 2x64 -- speeding
> things up for the 32 bit case.

4*32 == 256?

--
Manfred
(*) lots of drivers assume that, __set_current_state assumes that,...

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.048 / U:0.424 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site