Messages in this thread | | | Date | Wed, 28 Mar 2001 15:50:03 +0530 | From | Dipankar Sarma <> | Subject | Re: [PATCH for 2.5] preemptible kernel |
| |
Nigel Gamble wrote: > > On Wed, 21 Mar 2001, Keith Owens wrote: > > I misread the code, but the idea is still correct. Add a preemption > > depth counter to each cpu, when you schedule and the depth is zero then > > you know that the cpu is no longer holding any references to quiesced > > structures. > > A task that has been preempted is on the run queue and can be > rescheduled on a different CPU, so I can't see how a per-CPU counter > would work. It seems to me that you would need a per run queue > counter, like the example I gave in a previous posting.
Also, a task could be preempted and then rescheduled on the same cpu making the depth counter 0 (right ?), but it could still be holding references to data structures to be updated using synchronize_kernel(). There seems to be two approaches to tackle preemption -
1. Disable pre-emption during the time when references to data structures updated using such Two-phase updates are held.
Pros: easy to implement using a flag (ctx_sw_off() ?) Cons: not so easy to use since critical sections need to be clearly identified and interfaces defined. also affects preemptive behavior.
2. In synchronize_kernel(), distinguish between "natural" and preemptive schedules() and ignore preemptive ones.
Pros: easy to use Cons: Not so easy to implement. Also a low priority task that keeps getting preempted often can affect update side performance significantly.
I intend to experiment with both to understand the impact.
Thanks Dipankar -- Dipankar Sarma (dipankar@sequent.com) IBM Linux Technology Center IBM Software Lab, Bangalore, India. Project Page: http://lse.sourceforge.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |