Messages in this thread |  | | Subject | Re: [PATCH] Significant performace improvements on reiserfs systems | From | Robert Love <> | Date | 20 Sep 2001 18:56:04 -0400 |
| |
On Thu, 2001-09-20 at 18:37, Andrea Arcangeli wrote: > On Thu, Sep 20, 2001 at 06:24:48PM -0400, Robert Love wrote: > > > > if (current->need_resched && current->lock_depth == 0) { > > unlock_kernel(); > > lock_kernel(); > > }
> nitpicking: the above is fine but it isn't complete, it may work for > most cases but for a generic function it would be better implemented > similarly to release_kernel_lock_save/restore so you take care of > lock_depth > 0 too:
Let me explain a little about the patch, and then I am interested in if your opinion changes.
When unlock_kernel() is called, the preemption code will be enabled and check if the preemption count is non-zero -- its handled just like a recursive lock. If there are other locks held, preemption won't happen. Thus, we return to the caller code patch and lock_kernel() is called and everyone is happy.
If unlock_kernel() is called, and the preemption code (which hangs off the bottom of the locking code) sees that the lock depth is now 0, it will call preempt_schedule (if needed) and allow a new process to run. Then we return to the original code patch, call lock_kernel, and continue.
Or am I missing something?
-- Robert M. Love rml at ufl.edu rml at tech9.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/
|  |