Date: Thu, 30 Mar 2000 00:03:45 -0500 From: "Allen Pulsifer" <pulsifer@mediaone.net> To: "Allen Pulsifer" <pulsifer@mediaone.net>, "Alfred Perlstein" <bright@wintelcom.net>, "Mike Smith" <msmith@FreeBSD.ORG> Cc: "Matthew Dillon" <dillon@apollo.backplane.com>, <freebsd-current@FreeBSD.ORG> Subject: RE: Using packed structs to gain cheap SMP primatives Message-ID: <NBBBJNDFEKPEHPFCLNLHAEILGHAA.pulsifer@mediaone.net> In-Reply-To: <NBBBJNDFEKPEHPFCLNLHMEIJGHAA.pulsifer@mediaone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Actually, I spoke too soon. That's an algorithm used
to read deglitched hardware counters or ISR counters on
a single processor machine. But it may not be safe in
a multiprocessor environment where one CPU can read the
structure while a second CPU can be updating the
structure. There may be a way to update the
structure in a way that is MP safe, but I'll have
to think about it some more.
Sorry.
Allen (with foot planted firmly in mouth)
> -----Original Message-----
> From: owner-freebsd-current@FreeBSD.ORG
> [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Allen Pulsifer
> Sent: Wednesday, March 29, 2000 11:36 PM
> To: Alfred Perlstein; Mike Smith
> Cc: Matthew Dillon; freebsd-current@FreeBSD.ORG
> Subject: RE: Using packed structs to gain cheap SMP primatives
>
>
> Here's another alternative for reading structures like time
> that always change monotonically: read the values in
> "MSB" to "LSB" order, then go back and check in reverse
> order that nothing has changed. For example, to read a
> structure containing hours, minutes, seconds:
>
> for (;;)
> { h = timep->hour;
> m = timep->minute;
> s = timep->second;
> if (m != timep->minute) continue;
> if (h != timep->hour) continue;
> break;
> }
>
> The assumption is that from the instant you first read
> timep->hour until the instant you double check its value,
> it could not have wrapped all the way back around to its
> previous value. Or to put it another way, if it has
> succeeding in wrapping all the way around, having a
> correct snapshot of the structure is the least of your
> problems and the value you use is arbitary.
>
> This same method can be used to read the MSW and LSW of
> any counter-like structure that is updated by an interrupt.
>
> Note this method will not work for a structure that can
> both increment and decrement--it has to be only one or
> the other.
>
> Allen
>
>
> > -----Original Message-----
> > From: owner-freebsd-current@FreeBSD.ORG
> > [mailto:owner-freebsd-current@FreeBSD.ORG]On Behalf Of Alfred Perlstein
> > Sent: Wednesday, March 29, 2000 10:25 PM
> > To: Mike Smith
> > Cc: Matthew Dillon; freebsd-current@FreeBSD.ORG
> > Subject: Using packed structs to gain cheap SMP primatives
> >
> >
> > * Mike Smith <msmith@FreeBSD.ORG> [000329 17:03] wrote:
> > > > > For the single-process (1-fork) case, syscall overhead improved
> > > > > moderately from 1.6 uS in 4.0 to 1.3 uS in 5.0. I think the marked
> > > > > improvement in the competing-cpu's case is due to the movement of the
> > > > > MP lock inward somewhat (even for syscalls that aren't MP safe),
> > > > > the removal of a considerable number of unnecessary 'lock'ed instructions,
> > > > > and the removal of the cpl lock (which benefits spl*() code as well as
> > > > > syscall/interrupt code).
> > > > >
> > > > > I got similar results for calling sigprocmask():
> > > >
> > > > You should be able to remove the splhigh() from sigprocmask and run it
> > > > MPSAFE. At least, I can't find a reason not to (and it works here, yes).
> > >
> > > Just following on from this, one thing that I can see immediately being
> > > very important to me at least is a spinlock in the timecounter structure.
> > > Calcru and various other things call microtime(), and we're going to want
> > > to lock out updates and parallel accesses to the timecounter. What
> > > should we be using for an interrupt-disabling spinlock?
> >
> > One thing everyone should be aware of is that most archs will support
> > atomic read/write of a data value that's under a certail width (and
> > aligned properly)
> >
> > Yesterday I was looking at how Linux handles the gettimeofday stuff
> > without locking thier sys_tz variable, well it seems they don't care
> > or I'm missing something important.
> >
> > They just don't lock it, not that settimeofday will be called all that
> > often but it leaves me wondering what we can do about this, effectively
> > we can pack our tz (sys_tz in Linux) into a 32bit value which should
> > afford us read/write atomicity on every platform I'm aware of.
> >
> > In fact this can be quite effective for certain types of data structures,
> > even though our 'struct timezone' is two ints we can pack it into two
> > uint16 and pack a private structure, then copy it to a stack and expand
> > it into the user's address space.
> >
> > What do you guys think about that? Am I totally missing something
> > that makes the Linux way right/ok? (no locking on a 64bit struct)
> >
> > --
> > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-current" in the body of the message
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NBBBJNDFEKPEHPFCLNLHAEILGHAA.pulsifer>