Date: Tue, 29 Jul 1997 16:08:54 -0700 (PDT) From: Christopher Ulbright <ulbright@cs.washington.edu> To: smp@FreeBSD.ORG Subject: Input on spl changes Message-ID: <Pine.OSF.3.96.970729160200.31172G-100000@sanjuan.cs.washington.edu>
next in thread | raw e-mail | index | archive | help
Hello, In our OS (SPIN) we use FreeBSD as a source of low level(start-up, device drivers) code. At the moment I'm attempting to modify things for SMP. The currently unresolved issue relates to the use of Optimistic Interrupt Protection, often referred to as spl for system priority level. In FreeBSD spl utilizes a global variable, cpl(current priority level), to denote the interruptability of the process currently running on a processor. Any manipulation of the cpl variable is done while the "Giant Lock" is held (is this true?), which protects this shared piece of data. In the uni-processor version of our OS, we make use of spl to protect certain critical sections. The problem arises from the fact that we have a mulit-threaded, preemptable kernel. In the SMP case, the value of cpl can be changed by thread-1 on cpu0 then saved with the state of thread-2 on cpu1 when a context switch occurs. In this case, when thread-2 is run again, the value restored to cpl will be incorrect. 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. -chris ulbright SPIN OS Project Univ. of WA http://www.cs.washington.edu/research/projects/spin/www/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.96.970729160200.31172G-100000>