Messages in this thread |  | | | Date | Wed, 2 Oct 2002 19:30:52 +0100 | | From | Matthew Wilcox <> | | Subject | Re: flock(fd, LOCK_UN) taking 500ms+ ? |
| |
On Wed, Oct 02, 2002 at 10:04:52AM -0700, Andrew Morton wrote: > sched_yield() sementics changed a lot. It used to mean "take a quick > nap", but it now means "go to the back of the runqueue and stay there > for absolutely ages". The latter is a closer interpretation of the spec, > but it has broken stuff which was tuned to the old behaviour.
*nod*. This code has been around for many many years ;-)
> It's not really clear why that yield is in there at all? Unless that > code is really, really slow (milliseconds) then probably it should just > be deleted.
Heh, you're so focused on perf tuning, Andrew! It's not a matter of locking, it's a matter of semantics. Here's the comment:
* FL_FLOCK locks never deadlock, an existing lock is always removed before * upgrading from shared to exclusive (or vice versa). When this happens * any processes blocked by the current lock are woken up and allowed to * run before the new lock is applied. * Andy Walker (andy@lysaker.kvaerner.no), June 09, 1995
> If there really is a solid need to hand the CPU over to some now-runnable > higher-priority process then a cond_resched() will suffice.
I think that's the right thing to do. If I understand right, we'll check needs_resched at syscall exit, so we don't need to do it for unlocks, right?
-- Revolutions do not require corporate support. - 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/
|  |