From nobody Thu Dec 02 17:00:24 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 B994018C5F0A for ; Thu, 2 Dec 2021 17:00:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 4J4hzZ4T5Qz4l0B for ; Thu, 2 Dec 2021 17:00:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f53.google.com with SMTP id n17-20020a9d64d1000000b00579cf677301so449802otl.8 for ; Thu, 02 Dec 2021 09:00:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5/pwxfAyBbux1GDvybbxEZ8rMKtcQ3PoTU9qkLHAySA=; b=e3k0HbD4ANjYH/fvOC8iJaTVXCfrTE/q0yoFQwOeCMbVy2N8iCM4zgnR50JJlzoBkB NiizVVZcLrD/bxuBOvJ48mBpDqv2m9/hxmncPe4BN/PeiuYh57H+JH+7WL3rXkxMkPjF K06mhjRPtJKFO84rJBx+NjwVlwRlgPWb2UiWWPDjHyrxSJdnjL9eFHjPB+EVTwgrs1yG z6PgLNNeU/KOJ6xPrmD5I6sisqFC69zG1G8E+E7Jhj0TltZPizF3anzdOH3C5+oimhl3 RYJQ20U4/eeraCNuWvuvBmNMXE0oJ6lJj12A4q3rDXEHz/A2ZNXxf2JnWYMKlVui9893 A9ZA== X-Gm-Message-State: AOAM532/AfIdAL5AoowehLuvyWCpbSuRchnN73Jp+8mp3qUkXlWmLEji DAWlzY4moPgGEGZOw+fjSBy7o88cUYI7sO7rOAOBpWoF X-Google-Smtp-Source: ABdhPJwm8GQTMbzbFFJIBJ3I1YHgllXdgUG7fPJI4Oi7FQBp8Sdogi4iZRPfSWG9h6dRN5745uZ9B8NWv1Pg66MjPE4= X-Received: by 2002:a9d:7cce:: with SMTP id r14mr12011665otn.114.1638464435834; Thu, 02 Dec 2021 09:00:35 -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 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> In-Reply-To: From: Alan Somers Date: Thu, 2 Dec 2021 10:00:24 -0700 Message-ID: Subject: dd performance [was Re: Call for Foundation-supported Project Ideas] To: Stefan Blachmann Cc: Johannes Totz , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J4hzZ4T5Qz4l0B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This is very surprising to me. I never see dd take significant CPU consumption until the speed gets up into the GB/s range. What are you using for the bs= option? If you set that too low, or use the default, it will needlessly consume extra CPU and IOPs. I usually set it to 1m for this kind of usage. And what kind of HDDs are these, connected to what kind of controller? On Thu, Dec 2, 2021 at 9:54 AM Stefan Blachmann wrote: > > 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). > > > > >