From owner-freebsd-current Wed Mar 29 20:36:18 2000 Delivered-To: freebsd-current@freebsd.org Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.128.1.71]) by hub.freebsd.org (Postfix) with ESMTP id B09F537BC67; Wed, 29 Mar 2000 20:36:12 -0800 (PST) (envelope-from pulsifer@mediaone.net) Received: from ahp3 (ahp.ne.mediaone.net [24.128.184.250]) by chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id XAA03320; Wed, 29 Mar 2000 23:36:04 -0500 (EST) From: "Allen Pulsifer" To: "Alfred Perlstein" , "Mike Smith" Cc: "Matthew Dillon" , Subject: RE: Using packed structs to gain cheap SMP primatives Date: Wed, 29 Mar 2000 23:36:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20000329192526.U21029@fw.wintelcom.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 [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