From owner-freebsd-stable@FreeBSD.ORG Fri Dec 16 10:46:36 2011 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 8558B106566C for ; Fri, 16 Dec 2011 10:46:36 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm6-vm0.bullet.mail.sp2.yahoo.com (nm6-vm0.bullet.mail.sp2.yahoo.com [98.139.91.206]) by mx1.freebsd.org (Postfix) with SMTP id 5DBC98FC08 for ; Fri, 16 Dec 2011 10:46:36 +0000 (UTC) Received: from [98.139.91.66] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 16 Dec 2011 10:46:36 -0000 Received: from [208.71.42.206] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 16 Dec 2011 10:46:36 -0000 Received: from [127.0.0.1] by smtp217.mail.gq1.yahoo.com with NNFMP; 16 Dec 2011 10:46:35 -0000 X-Yahoo-Newman-Id: 977711.98480.bm@smtp217.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2lUakIEVM1kneLJNsjYYoqebdMFdkMHBhveZGfGBOsn4XGy Owk6nnn5Tcd7g8283JunWtIXe03_dcEt7HqwX7i6Xm_h9FcoVdw52ZdefSVS gde1oFe4_25VWsZoNh4SyFrB1Ki_4L5DJ4H1p8_E4SslzbC8qhrZE05FoIa4 NpG1beMdWvWrk2UO0ltZkIa8Q4lRniXKjDey.KCmMoTcfou8m1cpyIbd9Kcu U4EojigYBMs72.8YK9l_n1VH0i.uAxjxjfqte1Ba2wfyboloOe7fbbtUlzEY M_ZAIzK7ziRkSQ79w_9iYpCvdsKJSkVkW6SM2.g2sbHVs6nvL.XNXieumXhp 5pJlxYjQfYFsVRANOnxADYDucDHIKHmlfvpQO7.BFgDJRzcficeZfeHcjLAq EaurHQKgItuft X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.157.6 with plain) by smtp217.mail.gq1.yahoo.com with SMTP; 16 Dec 2011 02:46:35 -0800 PST Message-ID: <4EEB218B.1090209@freebsd.org> Date: Fri, 16 Dec 2011 11:46:35 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Luigi Rizzo References: <4EE1EAFE.3070408@m5p.com> <4EE2AE64.9060802@m5p.com> <4EE88343.2050302@m5p.com> <4EE933C6.4020209@zedat.fu-berlin.de> <20111215004205.GA11556@icarus.home.lan> <20111216081145.GA76297@onelab2.iet.unipi.it> In-Reply-To: <20111216081145.GA76297@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tom Evans , freebsd-stable@freebsd.org, "C. P. Ghost" , Jeremy Chadwick Subject: Re: switching schedulers (Re: SCHED_ULE should not be the default) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 10:46:36 -0000 Am 16.12.2011 09:11, schrieb Luigi Rizzo: > The interesting part is probably the definition of the methods that > schedulers should implement (see struct _sched_interface ). > > The switch from one scheduler to another was implemented with a > sysctl. This calls the sched_move() method of the current (i.e. > old) scheduler, which extracts all ready processes from its own > "queues" (however they are implemented) and reinserts them onto the > new scheduler's "queues" using its (new) setrunqueue() method. You > don't need to bother for blocked process as the scheduler doesn't > know much about them. > > I am not preserving the thread's dynamic "priority" (think of > accumulated work, affinity etc.) when switching > schedulers, as that is expected to be an infrequent event, and > so in the end it doesn't really matter -- at a switch, threads > are inserted in the scheduler as newly created ones, using only > the static priority as a parameter. I think this is OK for user processes (which will receive reasonable relative priorities after running a fraction of a second, anyway). But I'm not sure whether it is possible to use static priorities for (real-time) kernel threads, where priority inversion may occur, if the current dynamic (relative) thread priorities are not preserved. But not only the relative priorities of the existing processes must be preserved, new kernel threads must be created with matching (relative) priorities. This means, that the schedulers may be switched at any time, but the priority values should be portable between schedulers to prevent dead-lock (or illegal order of execution?) of threads (AFAICT). Regards, STefan