From nobody Thu Dec 02 16:54:04 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 36A8A18C255A for ; Thu, 2 Dec 2021 16:54:08 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4hr00lbBz4hQb for ; Thu, 2 Dec 2021 16:54:08 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x136.google.com with SMTP id bi37so10379lfb.5 for ; Thu, 02 Dec 2021 08:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UEbdmLQQsajT8voS0a3Lu7AQbkgKn0EkywGszB0XjKY=; b=NemWIwVzTQ2PP+Zsy5RzRCr5CDyHqqtP9g4xHL9rYLLnqO2nPusYG6M+Qng0RF5iyh HVuUJ8+NAzhGQ+WZDdpkxy16OQlZyfZSAYpdksxO21f9bk2bWEdO4jehY/WOXUOo1fyf plLhx1QWItC2PAdB13IF3JruQfwpPc4RAXy2zw3i1O3kTBR2zEJCp1pWmFpbSKQyuLSK 8cT5ESK3MMc2KpUm+64ocAqB+yitLdHn3XX7mRv+4LCLYshi2S35+eG5mzWaZ8pn4Xgr mmD3XPYyMk4ZBY/r1CJAToL36MltZpbxm8Blvb4rB1GjA32j9tendM/UphQS0WHeKkNB nPLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UEbdmLQQsajT8voS0a3Lu7AQbkgKn0EkywGszB0XjKY=; b=SuXyqldURXyBX2Db5UB/1iTE2OGqsK/nc6Z/gQeRKY7C8+pY3ctexVtLPcXcvJXIcX 6HXNiH+06WkqwLyDF+WY6ZMqwnkzeMlUqSDNTdkWi5dyHp2K+0u8EfDAVrZbxxI5R98U L6Pv7gOztHDpIOIjBYqOuo4c1dg5K8IkzFS+uiHhxb7ZV4bVfKpS9leviXLw/RDRiLyx ZNrAIcp0Jut51C7aUKOAh0i+Iu+yvysXtKelpfHNYsuexepN3MRB1J6fax9VVVq5rPDm 5yD9r26gCvATaI5UvNnH0JQ19SqpOAinHW2nYavN4L41VajC/ZgYaHC6LjqPCnwM23lR RvQQ== X-Gm-Message-State: AOAM5316iQq/l8zhkanY0lP15zQHvylEWuJwYz96CPUSiIB3NSQNkE9Y T7v23MTJ63dXhCKBU2Bdlgj2G0WqJn2gtyNA5KcDR6uM X-Google-Smtp-Source: ABdhPJyWFpfqtMSYlmOmucXk88vwZKqtprVBcc1+1GrHRc+fk7Y+j+YehugOWz3/rPBIB80FQ0LJM3sPD+tZxXuiqb0= X-Received: by 2002:a05:6512:e89:: with SMTP id bi9mr13175226lfb.465.1638464046073; Thu, 02 Dec 2021 08:54:06 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Thu, 2 Dec 2021 08:54:04 -0800 (PST) In-Reply-To: <01e739f7-ccb2-c59f-9843-9d5214032b77@bruelltuete.com> References: <861r36xzpe.fsf@phe.ftfl.ca> <20211128220732.GA81140@troutmask.apl.washington.edu> <20211129003635.GA81568@troutmask.apl.washington.edu> <01e739f7-ccb2-c59f-9843-9d5214032b77@bruelltuete.com> From: Stefan Blachmann Date: Thu, 2 Dec 2021 17:54:04 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Johannes Totz Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J4hr00lbBz4hQb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Regarding the suggestions to either improve or replace the ULE scheduler, I would like to share another observation. Usually when I need to zero out HDDs using dd, I use a live Linux. This time I did that on FreeBSD (13). My observations: - On the same hardware, the data transfer rate is a small fraction (about 1/4th) of which is achieved by Linux. - The first dd process, which erases the first HDD, gets almost all CPU and I/O time. The second process which does the second HDD is getting starved. It actually really starts only after the first one finished. To me it was *very* surprising to find out that, while erasing two similar HDDs concurrently takes about one day on Linux, on FreeBSD, the first HDD was finished after three days, and only after that the remaining second dd process got the same CPU time, making it proceed fast instead of creepingly slowly. So I guess this might be a scheduler issue. I certainly will do some tests using the old scheduler when I got time. And, I ask myself: Could it be a good idea to sponsor porting the Dragonfly scheduler to FreeBSD? On 12/2/21, Johannes Totz wrote: > On 29/11/2021 03:17, Ed Maste wrote: >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl >> wrote: >>> >>> It's certainly not the latest and greatest, >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz >>> K8-class CPU) >> >> If you're content to use a compiler from a package you can save a lot >> of time by building with `CROSS_TOOLCHAIN=llvm13` and >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. > > (re-send to list, sorry) > Can we disconnect the compiler optimisation flag for base and clang? I > don't need the compiler to be build with -O2 but I want the resulting > base system to have optimisations enabled. > Right now, looks like both get -O2 and a lot of time is spent on > optimising the compiler (for no good reason). > >