Date: Tue, 29 Jul 1997 17:58:27 -0700 From: David Greenman <dg@root.com> To: Christopher Ulbright <ulbright@cs.washington.edu> Cc: smp@FreeBSD.ORG Subject: Re: Input on spl changes Message-ID: <199707300058.RAA10698@implode.root.com> In-Reply-To: Your message of "Tue, 29 Jul 1997 16:08:54 PDT." <Pine.OSF.3.96.970729160200.31172G-100000@sanjuan.cs.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>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. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707300058.RAA10698>