From owner-freebsd-stable@FreeBSD.ORG Thu May 15 19:30:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08F541065674; Thu, 15 May 2008 19:30:18 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from mail1.webmaster.com (mail1.webmaster.com [216.152.64.169]) by mx1.freebsd.org (Postfix) with ESMTP id E30928FC12; Thu, 15 May 2008 19:30:17 +0000 (UTC) (envelope-from davids@webmaster.com) Received: from however by webmaster.com (MDaemon.PRO.v8.1.3.R) with ESMTP id md50002053351.msg; Thu, 15 May 2008 12:30:37 -0700 From: "David Schwartz" To: Date: Thu, 15 May 2008 12:29:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <482BFBDA.6060705@icyb.net.ua> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Authenticated-Sender: joelkatz@webmaster.com X-Spam-Processed: mail1.webmaster.com, Thu, 15 May 2008 12:30:37 -0700 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 206.171.168.138 X-Return-Path: davids@webmaster.com X-MDAV-Processed: mail1.webmaster.com, Thu, 15 May 2008 12:30:38 -0700 Cc: freebsd-stable@freebsd.org, freebsd-threads@freebsd.org Subject: RE: thread scheduling at mutex unlock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davids@webmaster.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2008 19:30:18 -0000 > what if you have an infinite number of items on one side and finite=20 > number on the other, and you want to process them all (in infinite = time,=20 > of course). Would you still try to finish everything on one side (the=20 > infinite one) or would you try to look at what you have on the other = side? >=20 > I am sorry about fuzzy wording of my original report, I should have=20 > mentioned "starvation" somewhere in it. There is no such thing as a "fair share" when comparing an infinite = quantity to a finite quantity. It is just as sensible to do 1 then 1 as = 10 then 10 or a billion then 1. What I would do in this case is work on one side for one timeslice then = the other side for one timeslice, continuuing until either side was = finished, then I'd work exclusively on the other side. This is precisely = the purpose for having timeslices in a scheduler. The timeslice is carefully chosen so that it's not so long that you = ignore a side for too long. It's also carefully chosen so that it's not = so short that you spend all your time switching swides. What sane schedulers do is assume that you want to make as much forward = progress as quickly as possible. This means getting as many work units = done per unit time as possible. This means as few context switches as = possible. A scheduler that switches significantly more often than once per = timeslice with a load like this is *broken*. The purpose of the = timeslice is to place an upper bound on the number of context switches = in cases where forward progress can be made on more than one process. An = ideal scheduler would not switch more often than once per timeslice = unless it could not make further forward progress. Real-world schedulers actually may allow one side to pre-empt the other, = and may switch a bit more often than a scheduler that's "ideal" in the = sense described above. This is done in an attempt to boost interactive = performance. But your basic assumption that strict alternation is desirable is = massively wrong. That's the *worst* *possible* outcome. DS