On Fri, 21 Jul 2000, Linda Walsh wrote:
>
> > 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.
> ---
> It is the 'huge' case I'm worried about. I'm an operator. I see a
> process that is suspicious. I set an auditmask on the process to audit more
> things. How long from a user perspective would it be before the auditmask
> took? 1-2 seconds might be in the noise level, 1-2 minutes would not.
None of this stuff should be more than milliseconds. But milliseconds are
an eternity for some applications. Building it with simple locking is
probably a good idea.
> I think the bottom line may be the upper bound on processor inconsistency
> in NUMA. Is it in user-noise level or is it a noticable user-time delay.
> If it can be the 2nd then a lock (perhaps we need a new lock that is a dummy
> lock for SMP, but a real lock for NUMA?) of some sort is needed for the NUMA
> case. Looking over the source, I don't see any references to a 'NUMA'
> variable to check for. It it is going to require different semantics to
> guarantee reasonable update time should there be one?
There isn't any Linux on NUMA yet, and if there was, it would probably be
at SGI. But it's something we've started thinking about and some of the
infrastructure is already in place, eg the zone allocator.
-- "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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:16 EST