From owner-freebsd-current Wed Mar 29 21: 5: 5 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 6D12C37B764; Wed, 29 Mar 2000 21:04:48 -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 AAA10557; Thu, 30 Mar 2000 00:03:45 -0500 (EST) From: "Allen Pulsifer" To: "Allen Pulsifer" , "Alfred Perlstein" , "Mike Smith" Cc: "Matthew Dillon" , Subject: RE: Using packed structs to gain cheap SMP primatives Date: Thu, 30 Mar 2000 00:03:45 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 [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