From owner-freebsd-arch@freebsd.org Sat Nov 14 22:50:21 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4B2C64677A5 for ; Sat, 14 Nov 2020 22:50:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CYVsn0sKrz4WW2; Sat, 14 Nov 2020 22:50:20 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id C246A8B757; Sat, 14 Nov 2020 22:50:12 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 0AEMoAVu015970; Sat, 14 Nov 2020 22:50:10 GMT (envelope-from phk) To: Konstantin Belousov cc: Warner Losh , Scott Long , Alexander Motin , "freebsd-arch@freebsd.org" Subject: Re: MAXPHYS bump for FreeBSD 13 In-reply-to: From: "Poul-Henning Kamp" References: <634E35E9-9E2B-40CE-9C70-BB130BD9D614@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15968.1605394210.1@critter.freebsd.dk> Date: Sat, 14 Nov 2020 22:50:10 +0000 Message-ID: <15969.1605394210@critter.freebsd.dk> X-Rspamd-Queue-Id: 4CYVsn0sKrz4WW2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 22:50:21 -0000 -------- Konstantin Belousov writes: > DFLTPHYS seems to be only used by drivers (and some geoms), and typical > driver' usage of it is to clamp the max io request more than MAXPHYS. > I see that dump code tries to not write more than DFLTPHYS one time, to > ease life of drivers, and physio() sanitize maxio at DFLTPHYS, but this > is for really broken drivers. DFLTPHYS is the antique version of g_provider->stripesize, and should be replaced by it throughout. The history behind DFLTPHYS is that tape-drives were limited to MAXPHYS sized tape-blocks, so you wanted it large. For performance reasons disk operations should not span cylinders, a topic I'm sure Kirk can elaborate on if provoked, so DFLTPHYS was reduce them to a tunable size. Peak performance was when fs-blocks divided DFLTPHYS and DFLTPHYS divided the cylinder of the disk. Seagate ST82500[1] with standard formatting had 0x616 sectors per cylinder, (19 heads, 82 sectors each). Formatting with a generous 22 spare sectors per cylinder brought the "usable" cylindersize down to precisly 0x600 sectors, which resulted in around 5-10% higher overall system performance on a heavily loaded Tahoe. Poul-Henning [1] The STI82500 "Sabre" is amusingly available for order in certain web-shops but, alas, "not currently in stock". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.