Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 18 Jun 2002 16:47:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 18 Jun 2002 16:47:13 -0400 Received: from dsl092-042-129.lax1.dsl.speakeasy.net ([66.92.42.129]:59654 "EHLO mgix.com") by vger.kernel.org with ESMTP id ; Tue, 18 Jun 2002 16:47:11 -0400 From: To: "David Schwartz" , Cc: , , , Subject: RE: Question about sched_yield() Date: Tue, 18 Jun 2002 13:47:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <20020618204237.AAA5802@shell.webmaster.com@whenever> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1137 Lines: 31 > >Now, if I understand you well enough David, you'd like an > >algorithm where the less you want the CPU, the more you get > >it. > > Exactly. This is the UNIX tradition of static and dynamic priorities. The > more polite you are about yielding the CPU when you don't need it, the more > claim you have to getting it when you do need it. > > >I'd love if you could actually give us an outlook of > >your ideal scheduler so I can try my thought experiment on it, > >because from what I've understood so far, your hypothetical > >scheduler would allocate all of the CPU to the yielders. > > Not all, just the same share any other process gets. They're all > ready-to-run, they're all at the same priority. Correct my logic, please: 1. Rule: The less you want the CPU, the more you get it. 2. A yielder process never wants the CPU 3. As a result of Rule 1, it always gets it. - 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/