Messages in this thread | | | Date | Tue, 10 Apr 2001 16:49:06 -0700 (PDT) | From | Nigel Gamble <> | Subject | Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel |
| |
On Tue, 10 Apr 2001, Paul McKenney wrote: > The algorithms we have been looking at need to have absolute guarantees > that earlier activity has completed. The most straightforward way to > guarantee this is to have the critical-section activity run with preemption > disabled. Most of these code segments either take out locks or run > with interrupts disabled anyway, so there is little or no degradation of > latency in this case. In fact, in many cases, latency would actually be > improved due to removal of explicit locking primitives. > > I believe that one of the issues that pushes in this direction is the > discovery that "synchronize_kernel()" could not be a nop in a UP kernel > unless the read-side critical sections disable preemption (either in > the natural course of events, or artificially if need be). Andi or > Rusty can correct me if I missed something in the previous exchange... > > The read-side code segments are almost always quite short, and, again, > they would almost always otherwise need to be protected by a lock of > some sort, which would disable preemption in any event. > > Thoughts?
Disabling preemption is a possible solution if the critical section is short - less than 100us - otherwise preemption latencies become a problem.
The implementation of synchronize_kernel() that Rusty and I discussed earlier in this thread would work in other cases, such as module unloading, where there was a concern that it was not practical to have any sort of lock in the read-side code path and the write side was not time critical.
Nigel Gamble nigel@nrg.org Mountain View, CA, USA. http://www.nrg.org/
MontaVista Software nigel@mvista.com
- 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/
| |