lkml.org 
[lkml]   [2000]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Cache coherency... and locking
Date
Ug...first there is SMP safe and then NUMA safe?

How do we isolate problem areas now before they cause random effects on a NUMA port?

Is this something we should be concerned about now or is it going to be one of
those...we'll wait until it breaks and then worry about it things?

For example, I wanted to have a simple 1 int check for auditing to be on or off.
That way even if auditing is compile in or as a module, it would still have minimal
impact. But it sounds like that global would have to have locks around it to
guarantee cache coherency. Suddenly that doesn't look like such a good performance
improvement. A Per-process byte might be a better way to go, less contention though
it sounds like I'd still have to lock even that.
--
Linda A Walsh | Trust Technology, Core Linux, SGI
law@sgi.com | Voice: (650) 933-5338


> -----Original Message-----
> From: owner-linux-kernel@vger.rutgers.edu
> [mailto:owner-linux-kernel@vger.rutgers.edu]On Behalf Of Oliver Xymoron
> Sent: Thursday, July 20, 2000 11:37 PM
> To: Linda Walsh
> Cc: Keith Owens; linux-kernel@vger.rutgers.edu
> Subject: RE: Cache coherency... and locking
>
>
> On Thu, 20 Jul 2000, Linda Walsh wrote:
>
> >
> > > To answer Linda's original question, whether it's necessary to use a lock
> > > is very much dependent on the operation you're performing. It's safe to
> > > assume there's an arbitrarily long delay before your write appears to
> > > another processor, but we're also currently assuming that all writes show
> > > up in the order they were performed.
> > ---
>
> > Arbitrarily long...no upward bound? A second, minute, hour,
> > day? Something doesn't seem right about that.
>
> That's the model, yes. I'm not saying it ever happens in practice, but
> things like halts, f00f bugs, software emulation, etc., might in theory
> come into play with a given processor's cache coherency scheme.
>
> > 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.
>
> > It seems the speculative read cache would only stay around for some
> > fixed, finite, and small time -- unless the processor is halted. I
> > can see getting the wrong value for the variable on 1 read, but after
> > performing a system call another read shouldn't still fetch a stale
> > value. Could it?
>
> In theory, yes. Not today probably, but on faster machines where the
> number of cycles to perform a syscall compares a little more favorably to
> the inter-processor latency..
>
> And it'll definitely be an issue on NUMA machines.
>
> --
> "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/
>

-
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.118 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site