From owner-freebsd-smp Tue Jul 29 22:18:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA09130 for smp-outgoing; Tue, 29 Jul 1997 22:18:56 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [205.153.153.234]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA09123 for ; Tue, 29 Jul 1997 22:18:52 -0700 (PDT) Received: from MindBender.serv.net (root@mindbender.serv.net [205.153.153.98]) by mx.serv.net (8.8.5/8.8.5) with ESMTP id WAA04125; Tue, 29 Jul 1997 22:19:01 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id WAA06147; Tue, 29 Jul 1997 22:18:43 -0700 (PDT) Message-Id: <199707300518.WAA06147@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: dg@root.com cc: Christopher Ulbright , smp@freebsd.org Subject: Re: Input on spl changes In-reply-to: Your message of Tue, 29 Jul 97 17:58:27 -0700. <199707300058.RAA10698@implode.root.com> Date: Tue, 29 Jul 1997 22:18:43 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>My initial reaction was to make per-processor cpl variables but this in >>and of itself will not solve the problem. This is because when thread-1 >>on cpu0 sets cpl to disable certain INTs, thread-2 on cpu1 could still >>enter some code section that thread-1(cpu0) assumes it has exclusive >>access to. Steve P. informed me that a per-cpu cpl wasn't a good idea. >> >>New idea: Have per-cpu cpl variables and restrict access to any FreeBSD >>code to one cpu at a time. Each time a thread enters FBSD code, it will >>have restored it's appropriate cpl value. If it needs to enter code >>requiring the masking of INTs, the cpu-specific cpl will be set >>accordingly. >> >>Restricted access could be achieved through use of a lock similar to >>Steve's mp_lock. >> >>Does anyone see the faults in this idea? Are there other problems with >>per-cpu cpls that I need to consider? >> >>Thanks for any thoughts/ideas/advice. > Hmmm. per-cpu cpl doesn't make any sense to me - at least not in the >current paradigm. We're using cpl as a global lock on interrupt reentrancy >and this is not a cpu-specific thing. I think the current SMP code blocks >having concurrent CPUs in interrupt code, but this restriction shouldn't >be necessary as long as cpl functions as a global lock. It sounds like what you're trying to do would be better achieved with "standard" critical sections, or something similar. It would only allow one thread into a specific area of code at a time, but would not block the other processor if it wasn't trying to run in that piece of code. This, of course, would have no affect on interrupt levels. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... -----------------------------------------------------------------------------