Date: Wed, 29 Mar 2000 19:25:29 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Matthew Dillon <dillon@apollo.backplane.com>, freebsd-current@FreeBSD.ORG Subject: Using packed structs to gain cheap SMP primatives Message-ID: <20000329192526.U21029@fw.wintelcom.net> In-Reply-To: <200003300038.QAA08006@mass.cdrom.com>; from msmith@FreeBSD.ORG on Wed, Mar 29, 2000 at 04:38:18PM -0800 References: <200003300033.QAA07919@mass.cdrom.com> <200003300038.QAA08006@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000329192526.U21029>