Date: Tue, 5 Jan 1999 19:34:06 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@hotjobs.com (Alfred Perlstein) Cc: tlambert@primenet.com, wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901051934.MAA13521@usr02.primenet.com> In-Reply-To: <Pine.BSF.4.05.9901051333120.37756-100000@bright.fx.genx.net> from "Alfred Perlstein" at Jan 5, 99 01:56:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Would it work if you had a thread per processor that allows requests > for object manipulation to be put into a queue? You could queue requests > to remove items from a list, and to allocate new ones. then you > can keep a lock on the individual objects and not the entire list. Sure. But then you'd have to lock the queue object while putting things on or taking things off. 8-). > Excuse niaveness, I haven't done anything in this area, I just love > thinking about it. I think the best way of thinking of the problem is an analogy that someone told me years ago: Think of the CPU's in an SMP system as spiders crawling over the code; the more CPU's, the more spiders. Most of the code is black; it doesn't matter how many spiders are crawling ove it at the same time. Some spots in the code are red, where global lists or singular objects are being manipulated. These are weak spots in the code that can only support the weight of one spider at a time. Maybe they are a result of weak spots in the hardware (e.g., you can't have multiple CPU's issuing INB/OUTB commands such that the agregate rate exceeds the ability of the bus). Think of how you would design an OS to minimise the percentage of red vs. black. At the same time, don't make it do that the only route between black areas is a red area, if you can avoid it, or your red minimization will result in a spider traffic jam (e.g., how would hou run the keyboard driver on one CPU and the PS/2 mouse driver on another CPU and make sure the delay for the LED setting still worked?). The job is to keep all of the spider's busy, instead of lined up to cross the same weak spot. Now think of the absolutely minimal, lowest overhead method you could use to keep the spiders from running into each other in the red areas. Try to not add any overhead at all for spiders in the black areas. That's high granularity SMP. Right now, the entire FreeBSD kernel is treated as if it were red; the same for Linux. For Solaris and SVR4, all of the kernel data objects and maybe a quarter of the kernel code is treated as if it were red. For Dynix (Sequent's old BSD based OS), all of the object manipulation code is black, except when a spider has to go back to the system well to empty or fill a bucket, or when you switch spiders. 8-). Then come the questions: What are the ramifications of each spider having it's own stack? How would you implement virtual spiders (kernel threads)? Would you assign stacks to virtual spiders, too, or only to real spiders? Why? How would you guarantee that there would be a spider when something important needed one (RT support)? How would you minimize the amount of non-work movement that spiders had to do (CPU affinity, cache preservation)? How would you maximize the number of free spiders working on the same area (SMP scalability, highest possible concurrency)? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901051934.MAA13521>