Messages in this thread |  | | Date | Thu, 29 Mar 2001 15:13:30 +0530 | From | Dipankar Sarma <> | Subject | Re: [PATCH for 2.5] preemptible kernel |
| |
On Wed, Mar 28, 2001 at 12:51:02PM -0800, george anzinger wrote: > Dipankar Sarma wrote: > > > > 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. > > Doesn't this fly in the face of the whole Two-phase system? It seems to > me that the point was to not require any locks. Preemption disable IS a > lock. Not as strong as some, but a lock none the less.
The point is to avoid acquring costly locks, so it is a question of relative cost. Disabling preemption (by an atomic increment) for short critical sections may not be as bad as spin-waiting for highly contended locks or thrashing lock cachelines.
> > > > 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. > > Actually is is fairly easy to distinguish the two (see TASK_PREEMPTED in > state). Don't you also have to have some sort of task flag that > indicates that the task is one that needs to sync? Something that gets > set when it enters the area of interest and cleared when it hits the > sync point?
None of the two two-phase update implementations (synchronize_kernel()) by Rusty and read-copy update by us, monitor the tasks that require sync for update. synchronize_kernel() forces a schedule on every cpu and read-copy update waits until every cpu goes through a quiscent state, before updating. Both approaches will require significant special handling because they implicitly assume that tasks inside the kernel are bound to the current cpu until it reaches a quiescent state (like a "normal" context switch). Since preempted tasks can run later on any cpu, we will have to keep track of sync points on a per-task basis and that will probably require using a snapshot of the running tasks from the global runqueue. That may not be a good thing from performance standpoint, not to mention the complexity.
Also, in situations where read-to-write ratio is not heavily skewed towards read or lots of updates happening, a very low priority task can have a significant impact on performance by getting preempted all the time.
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/
|  |