From owner-freebsd-stable@FreeBSD.ORG Sun Jun 8 18:48:09 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE364F87 for ; Sun, 8 Jun 2014 18:48:09 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 966D32E31 for ; Sun, 8 Jun 2014 18:48:09 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id g18so5002677oah.35 for ; Sun, 08 Jun 2014 11:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=d1hTtgdSCNEWkIsRV2LKdMenls0859knDJliNXjnLUs=; b=oKtT0t2iFxnXoLUvPD7mySW6Q+OiDsChMv/u7Htw8voYNn3RYSI+Tp0qMkMcd7cChb ca3/boS5ZUK7WSHAVUv7QHcTokT2jVAdV0/cV/OZoUrvXOUwMPbk97SlGbx5GJwbC9LL 1OK+7bYVhWFNuAf68vn5HcGiY0VWCHvYEAdUNQ8YIuNZFFrXMe5ecUF6kL11OQ4CoiRg uvsIepoHg6wcVUeJzwfyFnkRlBSRMvaqU4PRTdd0sMRv7FrZ+g/h5db4sc9z1kY5myq9 dOqG+ZLp4Th29ABCj+vw0jCoZdQcLDoHTaYM7/YZM2q6xMWNwiXRXgdt0UjcigKX0Kz3 EZ8w== MIME-Version: 1.0 X-Received: by 10.60.146.210 with SMTP id te18mr22313362oeb.44.1402253288293; Sun, 08 Jun 2014 11:48:08 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.202.171.73 with HTTP; Sun, 8 Jun 2014 11:48:08 -0700 (PDT) In-Reply-To: <5394A848.7030609@m5p.com> References: <5394A848.7030609@m5p.com> Date: Sun, 8 Jun 2014 11:48:08 -0700 X-Google-Sender-Auth: QX86nvI6g3Uo_9EilvEYSmVbeUo Message-ID: Subject: Re: Not to beat a dead horse, but ... From: Kevin Oberman To: George Mitchell Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD-STABLE Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 18:48:10 -0000 On Sun, Jun 8, 2014 at 11:15 AM, George Mitchell wrote: > When I run this command on 10-STABLE on a uniprocessor system while > running the misc/dnetc port: > > cd /usr/src > time make buildworld && time make buildkernel && time make installkernel > > On revision 266422 with SCHED_ULE, I get (showing the time lines only): > > 7045.988u 897.681s 4:00:33.89 55.0% 29430+492k 27927+17003io > 30943pf+519w > 1155.683u 149.422s 52:49.60 41.1% 25418+410k 7452+20843io > 12166pf+248w > 7.101u 4.838s 8:03.57 2.4% 5905+221k 1179+9461io 1345pf+67w > > On revision 267211 with SCHED_4BSD: > > 6950.087u 665.074s 2:40:36.19 79.0% 29929+502k 33651+17368io > 31151pf+151w > 1148.066u 134.312s 26:40.95 80.1% 26234+426k 9681+24613io > 11917pf+106w > 6.774u 4.369s 0:33.90 32.8% 3110+320k 1388+10979io 1514pf+3w > > Since the majority of my systems are uniprocessors and I like to > run dnetc, SCHED_ULE has been a dealbreaker for me since day one. > Consequently I can't use freebsd_update. > > The party line seems to be, "Well, everybody knows SCHED_ULE sucks > on uniprocessors." Hello? Not everybody has upgraded to multiple > core or hyperthreaded processors yet. Do we really want to write > off every uniprocessor piece of hardware out here? > > The other assertion I hear is that SCHED_ULE really excels on some > unspecified workload or other. I'd love to see exactly how much > better it does than 4BSD on these mythological loads. -- George > I am also at least ambivalent about the merits of ULE. The choice to run 4BSD does not prevent the use of freebsd_update. It does require a kernel re-build after the update, though. Just keep a GENERIC kernel (which can be downloaded for any release) in /boot. freebsd-update will use that for the upgrade. Once the upgrade is complete you can build the kernel as you wish, and reboot. Just leave /boot/GENERIC there to have it ready for the next time you need to upgrade or update. There is no need to rebuild the modules when all your custom kernel does is to switch schedulers, so it is fairly quick. This may not be adequate for you, but it does remove the need for many of the steps in the full system re-build. Full instructions for all of this are in Chapter 23, Section 2 of the Handbook. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com