Date: Tue, 3 Jun 2003 23:52:02 -0400 (EDT)
From: Bill Davidsen <davidsen@tmr.com>
To: Mike Galbraith <efault@gmx.de>
cc: Olivier Galibert <galibert@pobox.com>, linux-kernel@vger.kernel.org
Subject: Re: [Linux-ia64] Re: web page on O(1) scheduler
In-Reply-To: <5.2.0.9.2.20030529062657.01fcaa50@pop.gmx.net>
Message-ID: <Pine.LNX.3.96.1030603234616.16495B-100000@gatekeeper.tmr.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1500
Lines: 31

On Thu, 29 May 2003, Mike Galbraith wrote:

> That would still suck rocks for mutex usage... as it must with any 
> implementation of sched_yield() in the presence of peer threads who are not 
> playing with the mutex.  Actually, using sched_yield() makes no sense what 
> so ever to me, other than what Arjan said.  It refers to yielding your 
> turn, but from userland "your turn" has no determinate meaning.  There is 
> exactly one case where it has a useable value, and that is  when you're the 
> _only_ runnable thread... at which time it means precisely zero. (blech)

No, it works usefully without threads at all, with processes sharing a
spinlock in shared memory. If the lock is closed process does a
sched_yeild() to allow whoever has the lock to run. Yes to all comments
WRT order of running, if you care you don't do this, clearly. But in the
case where a process forks to a feeder and consumer it's faster than
semaphores, signal, etc.

All that's needed is to put the yeild process on the end of the
appropriate run queue and reschedule. Doing anything else results in bad
performance and no gain to anything else.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
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/