From nobody Mon Jan 12 08:46:38 2026 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 4dqQx26PHnz6NHcT for ; Mon, 12 Jan 2026 08:47:18 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dqQx13BQcz3jdD for ; Mon, 12 Jan 2026 08:47:17 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=iQ5h1o9l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cedric.blancher@gmail.com designates 2607:f8b0:4864:20::334 as permitted sender) smtp.mailfrom=cedric.blancher@gmail.com Received: by mail-ot1-x334.google.com with SMTP id 46e09a7af769-7c75fc222c3so3165434a34.0 for ; Mon, 12 Jan 2026 00:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768207635; x=1768812435; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=d1iG6YNfF4UI8wWvjtvL/vNbcvSw4Mauhh/tf+0Skvo=; b=iQ5h1o9lKqfNqdVFH9BnXS99iYWgdb+kGHh68s0I2LiuhSuFOS/HwNfi+azfT5zhC1 KXMT8eMBxd29Toisi+H2yUzQfY2QIK+uROl6Uoykdt5Mg9IQR3ZxMyhxkP5Kf74bVeEY pq06zeLh/SnGbncZ6Gj80Kn0mZ6NEygzuu8biRjblyaO5kZ+7LoxynI+Sg+U7Q6/aT1E 8pPRQ/YKj4svUou4VRyScm1G34NTzPyjWP0u6MKVjmg1jg5ZbsDwEUG6h9SIppEztxdc yhFYFPWR4cGR8FMmNSWzMsq4LM3uXZgNQUvVyV5u4go3Pbkb+pO21C+RVO3Myo8Dcwsv uCBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768207635; x=1768812435; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=d1iG6YNfF4UI8wWvjtvL/vNbcvSw4Mauhh/tf+0Skvo=; b=LW+URSMmDylSIqXYSf/ysx0DOYKKoFNc9BHRsAtjjqJ1uAi4N0tYcMuDZqCNN/scRT j/5qVdt0Q8+86BijGiB45U8WzMZc12yzUL8U8V40friHEtnGdzqhuI25qEimJYA8hZRs R203XCp+m4+DfhNyXpKG5Yxi4ziZ7tbfy5ejsoYtdhaXQcFL6plMzq84kGkJW8RcwFv4 kiUAdr2OH1Pqgn2a819FATi6avngFWbwKsezrUFCDyFXGWO+XGV0ZwT81qrmErkafd+x pRmw3ScfRKa1hfZXWM46+a7IHt+obUL6z28JYAS+CKpsGdsR8oU26EOWBH3mVuHuYzhw FZBQ== X-Gm-Message-State: AOJu0YyNgNpqlG69Y+Fhuoz9Ff4YOINfci1eQt/LUHJz0LtLpGDhWEbg GUPwgSw7c8rtMPE0AnaYVDLktwsOmRJ+dYlJu0P+lUFhYZeLmJryIQ8cpLa++YAm3whgEOf0Uxt XWy6eMoxD1UCDvkHHmp/DjNMcNreLMuG7ytt9 X-Gm-Gg: AY/fxX6kK8i+BFqlxA61xDH61qxSKyCD7qGrNenWeGrlZ8oRL1CA16gKdtlQrW2hKvA W5VThV89mwPmNEsw8DGUVC/9SqpNfefGwTBq7ioArEjrNkrT/MnIDEjUngZz6zQEA8fp4kUak29 NZmYoz93D5Q9Lvfy0s/Rzdox74AatxKqujJ9JIOzT8PGaZnrOTlgbHBHH+RMfycXjdvorVxO7sR Bov2owWzWBkotRADTZHtuoib7hhVR8x2tizk9bWra+6WSQkoOApNyy/YAt+IK/qLCtlJg== X-Google-Smtp-Source: AGHT+IGrdG4oAfd1YbZDs84zCGJ3Sl0UHkvCVhGqH6kM9jK5nEecY1SYsoJOhPZkoCzS0J/Guk15779zQl5KuW6gWuA= X-Received: by 2002:a05:6820:530a:b0:659:9a49:8e3a with SMTP id 006d021491bc7-65f54ed1d51mr5965276eaf.10.1768207634650; Mon, 12 Jan 2026 00:47:14 -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 From: Cedric Blancher Date: Mon, 12 Jan 2026 09:46:38 +0100 X-Gm-Features: AZwV_QiGGxisGF6_9RVnDG7vDvd1B8IeYjrkhPEiflavRGfxTe0D3E0smJEuK5g Message-ID: Subject: FATTR4_OWNER_GROUP supported at file/or creation time? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.26 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.26)[-0.263]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::334:from] X-Rspamd-Queue-Id: 4dqQx13BQcz3jdD Good morning! Doed FreeBSD nfsd support FATTR4_OWNER_GROUP, for NFSv4 clients who wish to implement newgrp support that way? Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur From nobody Mon Jan 12 13:30:07 2026 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 4dqYCn4KZCz6NbP5 for ; Mon, 12 Jan 2026 13:30:29 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dqYCm6GKGz3Nr8 for ; Mon, 12 Jan 2026 13:30:28 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=S9SKUNcl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::636 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-b8714a52072so167438666b.3 for ; Mon, 12 Jan 2026 05:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768224621; x=1768829421; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=stSDGW0V46dtXscK0+KXfgqA9i6mSbh/6/ZoM1O7rBc=; b=S9SKUNclnfYRYFlN4MySOsKANzi28pT3jLRQteAjcXveARDQTihRuSNh5L4vsW7Mzn rHmJ+hSoZk21QrTXdfvtCLPgHM49evEVsKdy3QefmqLrTMT6EPMhp+ro0dZgABpCZVht n4D+05I0YC1itgzAm2VCVjBRvts+THdGsr610VMRPI8OIluFR0XqPq0NkQ4wdV8jNVLR 1dvuJ0kbn4UDwGgQS7JNx6kq+Y2JLHqYnpadYXIseWTcmzgclSF3YReetPX2k8eNBsPI g6aoAgdFoRrLGZKta+ePgjDv5QUUnYniB2lhYZ24H+/50PABO+nixCrWD5ZwkwXTiyB0 Kn+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768224621; x=1768829421; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=stSDGW0V46dtXscK0+KXfgqA9i6mSbh/6/ZoM1O7rBc=; b=jdj9UxaaROmOxebunfkjXM0VxcM0sgJJ7gHDam6psE2Pti3MaD+CdWEgUvz1gDGE5j Uu+zF1RksagjtyOHSNpvwLxTs+Qu1A7+jy8nvxyVHTgt4ONvxU9Jpt0bRVk1831ZORAb HvDuLYO6Rr6Kr/jKWpLrn6RzqIun3NANEi/eJZLn6lfF8q4ODcPGAUXrcbSoWI7+Bvey 44ce6J5F2p3nRQS1H0WEjvjx1da4/DcgOh0Umv3wBJNkyUPiK8iKd3DiU8TxZ5zaFv3o th5JvT9VBg7Co/70faAMtKfKnUIB4GWvUFyOjv7aa4Iy3uPAH1yvGanXj9Xjx2R/VPz6 KpfQ== X-Gm-Message-State: AOJu0Yz6HZpnyhP/UNTPcxKlmbW0R+Jknz3DrC5oHLJE1pK16jqpYjf5 vsrTZgryzvKoCgYE5+ZPO0p4i6iimvtA6xu+4jSfzGxYjzhkz/RfRjVLCYJTpVj0ZT630tqQgCS I1W4dJhePWCqhqh5q0V68JCr00fc9Ag== X-Gm-Gg: AY/fxX4TBEuPA/7RfPJnvpX50VR/UCRabG9GpgAIYiLMb1Xaw1Rnh6gIYhXU5WdfQ2m 3P7+9AtGcNbEkPRMA6an07C9Ao8SWLYvmGCJz87RIvLX9HS7UoYaidtEI3vBuN/IZPT8/aZE8fs 8CGKh7nST4E9OszqfdAio5hHSjnf3ridkOzdKVS1pFAepCOObKeXY4hmSeBddHYidUq717ZQOMJ vsPFf5mVq8ONlYTJmZTKF1ubWm0hnHefkrtqdLcoIoyFpolbPo8GrtwpWJUBQcR3BYtsFe2OvKr AlO4VRu3mn4lO9ztxB7SxGDUICli X-Google-Smtp-Source: AGHT+IGlOWfUUSwnuk8Xhz4wsuXAVfk+DPMNz/tm5XW9vZgie4IL6qaq2+rhZQJoscrven0w6me9LEavKgtkZNrH3Bs= X-Received: by 2002:a17:907:948e:b0:b73:8f33:eed3 with SMTP id a640c23a62f3a-b844521983fmr1770180366b.26.1768224621230; Mon, 12 Jan 2026 05:30:21 -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: In-Reply-To: From: Rick Macklem Date: Mon, 12 Jan 2026 05:30:07 -0800 X-Gm-Features: AZwV_QhO9qJE1yNm-pnrETJaajg1Y9ys3IFnnGszeZthU7mlOY7xAN2ImJ-cwn0 Message-ID: Subject: Re: FATTR4_OWNER_GROUP supported at file/or creation time? To: Cedric Blancher Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4dqYCm6GKGz3Nr8 On Mon, Jan 12, 2026 at 12:47=E2=80=AFAM Cedric Blancher wrote: > > Good morning! > > Doed FreeBSD nfsd support FATTR4_OWNER_GROUP, for NFSv4 clients who > wish to implement newgrp support that way? Maybe. The code is in the nfsd server to do it, but like hidden/system, it is untested. It really comes down to what ZFS allows. rick > > Ced > -- > Cedric Blancher > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur > From nobody Mon Jan 12 17:17:08 2026 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 4dqfFN0gDmz6NrHj for ; Mon, 12 Jan 2026 17:17:12 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dqfFM72J6z3xtt; Mon, 12 Jan 2026 17:17:11 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1768238232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2vUnz99wRmUbeThoIinrlEd+Kt9gVnLM/eh+r1gI5m8=; b=AKVf4O+Lji+6lQTYRUoaOGs6uzBZHnIUpRYfpUnQFD8C0i0wPkwF8xxxwECUEQHChbxFml vu2j5u+TQcXmMJw+4ToP/poffeXSdpjFWnz8DGY5Exq0Et5Z4ok0cizVEKnv0JP1k7lwG8 3zt2LQd4V+YuVwgUKhgU6ZrZtdNNaetnzT6EZf7DTSQcib6HBxb6Cu55J4kw3PI4J6L+Qr 5INuEm0PA/oGo1y2ayYLPeEv/XDfyvQsHpm70kxaaScVSYb5VxySR1UkJVPyKh992LPEPZ 6SGoXfP7EtQPT+j97l+9Bp1AQvOcUhyTeyEdECtR28uwPRovFHGpKUBJhiuBig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1768238232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2vUnz99wRmUbeThoIinrlEd+Kt9gVnLM/eh+r1gI5m8=; b=PmlMKw8DNfnvPRWGsEu1aTVtHVeThHajY4O7Bs1tMzSB6IB61c5LRkt/8IhTBDq93FJfh3 L5IDN0x5uCkqpkJhhVNz+Jx3P3D0tBlqmt+AvpGqA2tk/Lr9aHlryjlxXxtdaXkd3mo6Kn gTzKWv3GJ8eCOkX8rnkgiGs/UkI/0Y1k2EHBge2tmXmro+nhbA7MguZPHABJOajrxQ8jUM CDat1T+n6b0vJT83ddbMJbS/9ddG7ri7LSeqaRQ+e3juVrRHWcAldzYyCdfmSDlrUq3JOm URRbvclGxAddQqDmgNgcL1s7E8hmABKDMloquGXnut2wrh5EkmD7YzOS/kFm+A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1768238232; a=rsa-sha256; cv=none; b=uVEFPDEkcoR/oSBF9cJrmAeoaCoR0A5D9MDdSmLmBA7QK7AjNu0m9UxThyP2sdSisHc33h QOWWKlhraq4SiAKGj/DuRjw5M9N+XPz4oEPvDZMXqbN6Ls/rc6bU2QMFxEqUqDn/BT9LSl 5dVPag0pgpCwsal3U30h8J4+lMztViMwlHSlicq4oYOdniZdqnBdfwzmGc/UvJwFe4zPrC eoyacu4iFO1/IBlw+JGbFDkutbwEF0uk1+zxQ+0gE0p5k8P5AhrLB/jrHfyqxIqJw8CQUe zIsDUGH94a5Of0/0MpSBtcqs0/K83U8LMnyi9a6tAIhucLyNq/KXCLq7wvCaXQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ltc.des.dev (2a01cb0585090500922e16fffef1acef.ipv6.abo.wanadoo.fr [IPv6:2a01:cb05:8509:500:922e:16ff:fef1:acef]) (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) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dqfFM5SS1zy0l; Mon, 12 Jan 2026 17:17:11 +0000 (UTC) (envelope-from des@freebsd.org) Received: by ltc.des.dev (Postfix, from userid 1001) id A50F611683F; Mon, 12 Jan 2026 18:17:08 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Steve Rikli Cc: FreeBSD Hackers Subject: Re: 'make check-old' says rm /sbin/ipfs, leftovers? In-Reply-To: (Steve Rikli's message of "Sat, 10 Jan 2026 16:25:39 -0800") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Mon, 12 Jan 2026 18:17:08 +0100 Message-ID: <86v7h6g38r.fsf@ltc.des.dev> 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Steve Rikli writes: > After a recent 14-STABLE installworld routine, 'make check-old' said > /sbin/ipfs can be removed: This is an optional feature of ipfilter and has been temporarily disabled due to multiple vulnerabilities. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Jan 12 19:51:21 2026 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 4dqjh42Vjdz6P1m8 for ; Mon, 12 Jan 2026 19:52:04 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-oo1-xc34.google.com (mail-oo1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dqjh34Shkz3Wmn for ; Mon, 12 Jan 2026 19:52:03 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=SXGE+jkA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cedric.blancher@gmail.com designates 2607:f8b0:4864:20::c34 as permitted sender) smtp.mailfrom=cedric.blancher@gmail.com Received: by mail-oo1-xc34.google.com with SMTP id 006d021491bc7-65d132240acso4161345eaf.1 for ; Mon, 12 Jan 2026 11:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768247517; x=1768852317; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=eOY8mWsw0x2AUhNa29rD5WcjUh4aoaqTF/VBXKDowks=; b=SXGE+jkADBVy4wsbqLRbi4+/wrBg9Z7K0z3WoKWoQPOTyITP/lvScaKjy1o/fODu4h 9Js2dcJVYfsxFPWFfhOhdngvNVKg2bAvZFloQlGcceMgag4lCxPRagbNJEDlD2AuAJrm 9NAdoUcq4XOi7TS9Sxy1ZCVo1eTfxzxYLqnQDHe4u1NxgSGr4oHq1mLFUHGxcBAXfT0s qdZ4/EahHTPBRE0a5antBncyLKucupet/CDj2Ia6frsh15/4FoxO98lP9bJ1g+rn2jBR XJ2lz6+B0TPsUs+EBhAZ5zTHE6b69CdjfYI+zm1IQCw/AjvY15aX6YADnd7rWhDChFrn 7INQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768247517; x=1768852317; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eOY8mWsw0x2AUhNa29rD5WcjUh4aoaqTF/VBXKDowks=; b=dixPx0/G1yHaB5LGxFkAtIxNY2/FHAD0LPtfxnbAvX3jGE+SUobDor+Qedivll+Wpw sv1nxHszFJqDGx/xb20cE1r6hceZFy71RbchNpupMLa0zF/Wd3COHLqJBCHjw0woAXT9 7pMqhQQIq7+qogDXB9INXLMTlKfwT4toYHLW2p4kvgm0HC7MoreRRa/2jBgUNvPmte5h vIIHSYCR1C6UpKxC3gyqWeWaf4ns6Kmb9vOlOfqeXsLKX5NJcvKP+EuD4wilDjzgYxsj /NSvRDp3eqH7Gd1qAn4Qbgw/2uKKnJfOOAEfPQTZ2nK/0kDiWA0xB8a6s2EpqnKVxyCL 8EEA== X-Gm-Message-State: AOJu0Ywv1GBqzJ0UUZsr9tFiw1FcGP5BoA3KeGIg2mPOH5ZkDSPxHolU xbpUpn1NUy+y11ztQWCKIQTfE3UzmEgOqkNB/f5icF3vb0S2TI6slUIZk9ThcbtiH5VS7Xyf82l lnu78JAeRLqut2QIqG4QyPgukBoCoxXCMs5J0 X-Gm-Gg: AY/fxX6dhZELADxeggalMcyWdgEZRvCRAuTaXZBQsWOuZYy31cLj1392kv7c+VYQ6ao ylF5Jfp1+BFsX8hShvul+79RNcWorHR+B8Sjtas3U13eea1XcBTduMq6OirOZsuRk9YelU4yVh/ Q8Wvo0V0zVCGuojsiCHjyLg78g/5nXR9aLnPlEHb7Amf2Ue+yS71wFF4nwlfLPKc1wP536/SMJv xsnlVZsDnAk1Nab5x9j239r4gFXV4JBkcZCiyyoiPlehK4VeoThw1UXhJXaTf3qrwR+kyw= X-Google-Smtp-Source: AGHT+IHHyKGHIUVEtA1fg6suZ1eIjGO8KH7cnDEEHRJy7eaRZegKpQCCXMdhI+D3W8S6ZsKM+P7AZmurHHnBbYIH4K8= X-Received: by 2002:a4a:e915:0:b0:65b:31cf:ca92 with SMTP id 006d021491bc7-65f550886fbmr8575844eaf.84.1768247517569; Mon, 12 Jan 2026 11:51:57 -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 From: Cedric Blancher Date: Mon, 12 Jan 2026 20:51:21 +0100 X-Gm-Features: AZwV_QiuuwhtzYLzez7ugDMfdkNF-3CGNzCJQXnki3VDsDtYtzm8HjlwjzdY9Qc Message-ID: Subject: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.69 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.70)[-0.695]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::c34:from] X-Rspamd-Queue-Id: 4dqjh34Shkz3Wmn Good evening! Does the FreeBSD >= 14.3 NFSv4.1 client and server support case insensitive filesystems, e.g. exported ZFS or FAT? Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur From nobody Mon Jan 12 21:56:37 2026 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 4dqmSB6vRJz6P8FW for ; Mon, 12 Jan 2026 21:56:58 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dqmS96rsrz3nbf for ; Mon, 12 Jan 2026 21:56:57 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=Ee7f1Roh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-64baaa754c6so9879896a12.3 for ; Mon, 12 Jan 2026 13:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768255011; x=1768859811; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=w67qsJPSkSpSAjrW3gcmeaf6ityntY2ddgINxFCoNLU=; b=Ee7f1Roh8WKHPAdTFNY3aatldFmtusqmXkhDwqPvYCDvq/pThKtGYarpEtpfxPK1WM C0cehQP0r1m3i9sDlH67ePpaiitSthi6Xns7/16FwaZvDfczkxvE5446RxGYNtxVJr2/ X51cjR0kyXtwt7qOgmYWEpRhhnS+4MPIjRCCEbztUXKsOKokUjLtZ4KAD8AVXCqsoVFQ AdmXnZny46VjddV9D6hc2Cc1nMEZMSczJoT9dSxr3X01RrYYaIt7gN4m0+fSJaGSR0xC UW7fVxKqqX7pds5F26QHZe5jZm/0rs5BSVpx3wpgEL1rKyQxw9AkJbiPJ9jgeRxrqACb vpIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768255011; x=1768859811; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=w67qsJPSkSpSAjrW3gcmeaf6ityntY2ddgINxFCoNLU=; b=TZJ3ybgKbppKDTmOHd1RiJZLGRewPN8OSlHJwR2diTwh6F3pi39399xgXsxvRR/9GQ LZ4XKXi9kP93H13z1dLL9ZOFH+3LMOMXt5KZFL545AgTFQrnYHGkc/JIF6657UutxS+a w6stuF//Rbvvn1qgJttJCQSGxmCCqaJ6J8wMvakZhzILjAxfrIyul5PSco87kH7B+Zkm ozxtjyI9/5m7ac4MCVxQ4v4X4UjPr13ysljsS1C+2Bd4xEIx+huuyV16zkAqoX6tqN5v 0RA0/ORyZr6B2vBM5CrtWh7fRqFPifArhhMRC6Vpn5TKmyvUMtd25J1zlLQ35NP6zXZf sByA== X-Gm-Message-State: AOJu0YxiEzwJosI3A2wyIKYvnZXTL+ZfFmVqagT2i12l43w9vfz3L65q 6U4sUZrup1JnckAfJulwDZKOKdJnUimEwb7tEiYiKKKJafhjPXT+DcKB5lDCQ2JpswKn2wCyR7p pn41/2AQUbMEJPHr5ezcduoHrimJO7w== X-Gm-Gg: AY/fxX4tGdgG7ZAbsJAONZfd+6q/zO9ulhrqqOE+c2NGOFZZyJQETtR8Q5aYJieRTKU Zo+t8NjotnYcJlvlsW4aiyieo8Z+y3CxP3vylE2++rjFlleHCQ6rXYj8lliZUAKhrD77P7+nu8V ZYfnQRq3ak1iNwAOaTDcvpM4mROhxzFDuaw+bXGFTQsLriP+3o80NtSzM1873lhMe/QUNilfOwk ndJA7Oshuf6SK26HMQRxJcyXkL4e85Y7cc4XHZtRFS9xv8BeTYP0MWSb07GKgwRQCGyNxLkTTox OiLNI7iBP2OSLW3BkrOZnM18FmAy X-Google-Smtp-Source: AGHT+IG5RgjESXnSLCsYJCbUHvthUCN97NHd2a/jF8X/zAbZsDPtAjwZulMmgTC60YNQlLge/hmC9n5Gidg1JABJWOk= X-Received: by 2002:a05:6402:50cc:b0:649:9159:243d with SMTP id 4fb4d7f45d1cf-65097e4d23amr17970799a12.22.1768255011355; Mon, 12 Jan 2026 13:56:51 -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: In-Reply-To: From: Rick Macklem Date: Mon, 12 Jan 2026 13:56:37 -0800 X-Gm-Features: AZwV_QgG8D8-3h6Wi6K5_x0EaF_PSAwodlIDQl5Q7O4htRJSue-ITccwQRI1p10 Message-ID: Subject: Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: Cedric Blancher Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.97 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4dqmS96rsrz3nbf On Mon, Jan 12, 2026 at 11:52=E2=80=AFAM Cedric Blancher wrote: > > Good evening! > > Does the FreeBSD >=3D 14.3 NFSv4.1 client and server support case > insensitive filesystems, e.g. exported ZFS or FAT? Greater than, as in 15.0. For ZFS, the file system must be specified as case-sensitivity=3Dinsensitiv= e when the file system is created with "zfs create". You cannot adjust the knob after file system creation. rick ps: I'm not conversant w.r.t. ZFS or internationalization, so I cannot help w.r.t. what case-insensitive means for non-ascii. "man zfsprops" may give you this information? > > Ced > -- > Cedric Blancher > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur > From nobody Mon Jan 12 22:04:37 2026 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 4dqmdH3hzxz6P8vW for ; Mon, 12 Jan 2026 22:04:51 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dqmdG69Kdz3psW for ; Mon, 12 Jan 2026 22:04:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=V8ZqsqjL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-652fec696c9so278834a12.3 for ; Mon, 12 Jan 2026 14:04:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768255490; x=1768860290; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BV38R3EcrUMZpiVmLZ8EJD2ve6rKP950n7lpzMst8w8=; b=V8ZqsqjLaiO/z3IdKFqcqfEA9DYbskqgIreuLsgyq9g7byB3KUtUFqLkegksfa2GWP cjzUnG4JLHdp6mWxqPAG7ocPwRWqLIpPKTqXpafrzplpDcCtDBfOH432+OWGUiSpg+os NIlf4kAvODoC6K5EMBML3dUgFKJWW4h7DsE16Zo8KcFb67Cu5ixmYxhBtntuU94qN1BF C//P52PHCEWYdFKzBrPPyf4J9wh0uDKa90UVfH3dDaj7HbGOmTW8xEyvnTWQfAPnah3P fRh47swArwS4EZT+chbdc+td8AxQzMwaiqQglEnZ80PwCE31dPcNWa6/IqNcxTFyqmfH xC1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768255490; x=1768860290; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=BV38R3EcrUMZpiVmLZ8EJD2ve6rKP950n7lpzMst8w8=; b=FMzYamACg9kPcU2T/fmJIg0KGKH1IZ2HavMeTZRnpr6wnAk+4gloRp+z8/WzC6kKuN dyFdsIBtc/V9QFXRdt2FzfTClCyr2odUHk371yfPunFa0CEOXEsSkhgBvJlrettnInLA yrLSOzgB0ePucmYdIGVlfc9dYQMK+E99SyHPD5G68rzhOaAEDOvTFJVMy7u0QuM0CqOh i7CUzEue3L46MtG4yLqNtbnzP0XeOP/ZxoXOIwkULm3P49+z8SENuxjtR9vTQeAewKyl TrpYSLxY7t0wu/8gm/UWtxizvJ8A5Ahmglqho4tvNSrIRG9OXG6DjT4a9V/cfwxNHF7c 1XCQ== X-Gm-Message-State: AOJu0YxWg3o7AyCPNL9daFGlvf7VfNu3Ax3cvwRZvzrxSMmDXVrt/diF eRpYZwKzmAFVMFvp4jtkolm2RxoSLISDgxQiqakiM3rGz8JzaJlL5CjXcIbQTMc9tJJeIFrRD8K vnsFROq6fnShb87uTMm75+8mGdYCrnwbgYOY= X-Gm-Gg: AY/fxX6AWeS2JNhnGGBPrzpqUIKwa+C29vX/H2FqbHhrKBakDsMsDoav+/+UlpSRoZf JxG39AqIfYp57vN1GSOQHscfAL+Solr77ezNWOw16JIY1/cvEosORsARCwald6fDyNufytP4Zdr D7tXgXNJbIkXkJEM87BVLhczfnCieHZkhXuDguFIOJkKu3qpyf15IR7ZBhGFF7TaNPP21BJlQKO vEAomGYg4g46hPmhzZyTlAODSPRXJvrUaKHG4pTwDIeu++/5loyWEUGNpIjE4j/+OU/IeINi2B1 6wE+jukl2CNXQsNrc2h5L7OigaPvimSOqyTlhpw= X-Google-Smtp-Source: AGHT+IFIIblnFWptaEdCOSVnrB2b8PcNYxMseXZYmOprMmnOJyQYZby87mV5oOoDewLwH0lQMzVH8L8P0oNEPQU8Cdc= X-Received: by 2002:a05:6402:430c:b0:64d:589a:572b with SMTP id 4fb4d7f45d1cf-65097e46aedmr19296712a12.17.1768255489565; Mon, 12 Jan 2026 14:04:49 -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: In-Reply-To: From: Rick Macklem Date: Mon, 12 Jan 2026 14:04:37 -0800 X-Gm-Features: AZwV_Qg2m3uMwLfUqy3Bc0Ka8hwPPx8gkkUoB8qzgn-jrke1xizOYndEO4kkHLw Message-ID: Subject: Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: Cedric Blancher Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.97 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.974]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FREEMAIL_TO(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from] X-Rspamd-Queue-Id: 4dqmdG69Kdz3psW On Mon, Jan 12, 2026 at 1:56=E2=80=AFPM Rick Macklem wrote: > > On Mon, Jan 12, 2026 at 11:52=E2=80=AFAM Cedric Blancher > wrote: > > > > Good evening! > > > > Does the FreeBSD >=3D 14.3 NFSv4.1 client and server support case > > insensitive filesystems, e.g. exported ZFS or FAT? > Greater than, as in 15.0. Oops, that's 15.1-> (I looked and it is in stable/15, but not releng/15.0.) (I work with main and the stable branches and don't keep track of when the releases branch off.) rick > For ZFS, the file system must be specified as case-sensitivity=3Dinsensit= ive > when the file system is created with "zfs create". You cannot adjust the > knob after file system creation. > > rick > ps: I'm not conversant w.r.t. ZFS or internationalization, so I cannot > help w.r.t. what case-insensitive means for non-ascii. > "man zfsprops" may give you this information? > > > > > Ced > > -- > > Cedric Blancher > > [https://plus.google.com/u/0/+CedricBlancher/] > > Institute Pasteur > > From nobody Tue Jan 13 20:28:42 2026 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 4drLSj2DMyz6Nfck for ; Tue, 13 Jan 2026 20:29:25 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4drLSh4kQRz48P6 for ; Tue, 13 Jan 2026 20:29:24 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=T84CRr6a; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cedric.blancher@gmail.com designates 2607:f8b0:4864:20::22d as permitted sender) smtp.mailfrom=cedric.blancher@gmail.com Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-45c60b650cdso970981b6e.1 for ; Tue, 13 Jan 2026 12:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768336158; x=1768940958; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AON2qkUh8Xf5rgWywCPEK2U3xcs8chI3NfpnnGEQJpI=; b=T84CRr6arrA0pJjIqgJ/lxJEUzo7Arrzemcs1b7elzOnMsPm7d0lOKLVfOsVZ3H2iS cMe/wbwGV7t4t1Kifismy/QaxnUj1ByBhUsEJyJ7pXgaq2s5YdGYujvutVu0Myaxuu13 GZ2Y1/IZO0J584fY79M7iuok1Kkek031v5NfiU+fwh2UKBPblxgh1U79MmQvLrawiJRE t0s/El7qzP1+1Yg5eixEr0e0K/VwX/E8HM4EDstCXIfkoDmTEZkzVxYIEFTWBMpTUlTr makfXQvacPChYQm7BsRmdONx2cjOgx5AVF6ZYt1U2mrC8CC66WyuatRa4SJY0XNHEmhY H5IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768336158; x=1768940958; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=AON2qkUh8Xf5rgWywCPEK2U3xcs8chI3NfpnnGEQJpI=; b=k1wMgWr74NMgmZ8Ty4575otWtgtd3aP4PNabcjCBLz/URxIyPztrzzHPNglzbehPD6 o5/23muyNinve8J3toDPywCkM/OEoaTF43pe1B5WP4AzNZJocsHPys2D/I+QTnOyajfv iLXciES1iOt2yMU4OMI6vb0IFAdQVJ3HuRfHVX0YeWyR6HD/HVthTq7fjJ/OnZl9Pb3G /mf67KJZEEPcpxBjVtS8Wbr/eoyR9jmX/3gta3ufp9hudRuV6CywYUH21s4jbNVrugVJ I8dVYdk7sjxB4hno6L5gCQEWoFusU0+e97HPPyCiTlOEB6oVb5sRxUE9WzXcn9QZFkwz /UBg== X-Gm-Message-State: AOJu0Yw6fGzMXm6rsU7LxxuX+8Dn5I5/RbuCfvGz9/Jx3ieXPkdE4+9l 2t2uBN9wuv3n+YwIY8soqu/hRZypM6sPWBXXQMiYfUbo1Ldjrvk/zUjS6iym2SpQh+V+zJdkgu+ q+hfkcyEGPhz1OkBSNrQwFoJQY+Z9xx49QtpS X-Gm-Gg: AY/fxX4ePwq58NMDJVdOObxVMkpVWKhjGLO+zvGOC/BPVJNJk9cm9GCwmWcC9U7nP1u ieiZjws1gU5BkQQtfFeOt4WHCnqyk3GyDFeIPnuinyty+WNoGUGHY1jSAlVHb1/kTTJFgM0vJwP KiouVrUitj3YU6SKZ4UR/8utL/ZiAXVQ1laF935uoqqHXIlU1FZctH/ctc5gSOna/XqZiB2htMr yr4ylj/94zSFxtn5LQvKgOB2aLdRN5+I6GxYm4NbSGjD8JLJxbW5lY= X-Received: by 2002:a05:6808:5286:b0:45a:54f0:7b0d with SMTP id 5614622812f47-45c7146332emr130616b6e.13.1768336158318; Tue, 13 Jan 2026 12:29:18 -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: In-Reply-To: From: Cedric Blancher Date: Tue, 13 Jan 2026 21:28:42 +0100 X-Gm-Features: AZwV_QgxA-sfptXQqwKmyu58KZr5sZ0p3Ec_s_5QUOMMRb5unv_Fk6goei4Iitw Message-ID: Subject: Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.59 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.59)[-0.586]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22d:from]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4drLSh4kQRz48P6 On Mon, 12 Jan 2026 at 23:04, Rick Macklem wrote: > > On Mon, Jan 12, 2026 at 1:56=E2=80=AFPM Rick Macklem wrote: > > > > On Mon, Jan 12, 2026 at 11:52=E2=80=AFAM Cedric Blancher > > wrote: > > > > > > Good evening! > > > > > > Does the FreeBSD >=3D 14.3 NFSv4.1 client and server support case > > > insensitive filesystems, e.g. exported ZFS or FAT? > > Greater than, as in 15.0. > Oops, that's 15.1-> > (I looked and it is in stable/15, but not releng/15.0.) > (I work with main and the stable branches and don't keep track of when th= e > releases branch off.) OK, version confusion. :) What do I have to do as FreeBSD root user to update a FreeBSD 15.0 installation to a kernel version which supports case-insensitive filesystems for NFSv4.2 server, i.e. FATTR4_CASE_INSENSITIVE and FATTR4_CASE_PRESERVING are set according to the features of ZFS? Ced From nobody Tue Jan 13 21:41:32 2026 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 4drN4B4n7tz6NkgH for ; Tue, 13 Jan 2026 21:41:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4drN4829NVz3Hv4 for ; Tue, 13 Jan 2026 21:41:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="d5Zg/u/O"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768340499; bh=xOLpX7kgNzIraOe71C47oclykEv8rAUxl1EMa2u3z7w=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=d5Zg/u/OxqCT0HHz5DIqtAOfX/+YEy3v3HJRF15aB8WQyuJqJgECo2xYWIkr1GnwbLlC6teFPLgtHp0R2ryDylkgwwS4F7mWKIJHbXL6RK35UfDBOIaJD2V1Jtbn8mOZFkW5l6STmQyRjhDo2wtai/bgRlHVh//uOWvSWscSPUUNHZxnxV9Qflp73Vda0kENvns1coQHsrDuPsuWPSVWMiEILpVRxe9kE/xV11pAwF3Irbc/DY/8KOnaxlUga23BSClR04qCB7ZRIQDaAs9lXieOXVf07J+WxvheG4caE5RVi2UD8MSAU5k20wjX9gB168mmCWctLSHODv1PV0usZw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768340499; bh=+nmCMoJL77HhvfCM6PLqw3pZyrk2NUESPYxCyEIh0Wx=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=l9gSQaGrZYuNtRgfsq5bDXimCypFdKC0Ugl1r3NYPh2qVDTQmjF1ctewBMjo58HVd3153g2tAMXZh9TLSKRepcZYnCtDQakrsEUZBhgPpwBSLZZvEzHO9Gy7ToxFC4kRIHJYgc9t0AcJ6dipCyyrOtOcC1Zz5VLQbkDHUxvQiC3hlZJm2wUNcTpW/TK7iHeUuCYzlv6auyc/0rfbYudXmHeacmK4JMoVhattP2y8mc+l1ZP/BqUsEmHwT9F8Gbx4ABZIZlmJ4cH8FBexExzqCny2jI4G+SEP8Zi+LFHhuRQzmY8wgdytl4CHcoDaWKs5Ci4EqutP4JMKWGakcs87hg== X-YMail-OSG: OMNiwTcVM1mQpib8wT1fOtUSwWG36wezV3YeQP1zChZPRHtfsoJy5PmDU2gbM45 O31CdvbJv_O_G4KScoPZZUosC0KODTU6NYi0.tpcIKlanhyPUsaPcb6RTeCXjEMi6KypQ6U4UeSA LRaFuxclfsjdLBKt8Gex5JAsAlGTM2II4dsaR5Zbfesufa1dS_vfj198AacCyl.1ndzuull3bXBy YlDNtcY1GHVzwM92TFa40TPARjdMXAt00gsBrqLcUoinoodsYwnWcfLY9AMXTzI9Mfi7jZ15hlvg ezenbyaq8CaCAYHUrYgneB978Wvja2t6cd9tM2BOwY_JJsk_MUutsoJxt2StCFl0X_HAaOmxVq4m ARpJ_oMlF60KL30Vrlx1kv5Gyk2ae2rgKc7jTpD6yfsH0vUrgtUxNryEpGo1IQoWmKB_mYmy3g5L 5w40lDGBALavzMazpcI2AqiprkthvxwVKDhBjvIu3EcVSdRbnyd3GeXXdzxdNTdcrx5EtNXnwWQw zf_xKEXHn6IubEchzAUxvAoTyKvszM.FTY2sM8yySLAQJ3z4AWGI2SZi2WBe_1cTPqW5OUlcR0J6 FN2Zzs53VaJaZV_eJe2gB38y1i0wUAogpb29AloX2K1GX_UxtlD_mZiYd51udiQjYc1gspD8zzyw iBpAu3zbdKxFqUhbzQKcbfcmLFs1kX0HsuwRpnXR.IF_HNtIgQG4iJV4g1aHuFwouLRzHzMpHg90 gfrx2TtpXGCqu1Yj2hJugXSd.0eN2a0xrN3cNuR2PiCySBfPilSdPCl445nmVm3OqvnQM3C5F6pm TSog0g5F7PYK1SqMWZS_RlVKpmuXa1CVW8Mn2rLiJDK9JS81mPeVhEHgUIAh4PjPSniZzUcIBoGz IAL4w9dwjUgDsSdaf_ksfWwUe.JhwUZYttdgVEBmgTgPerfV_QNff3Pno393rEAnbpJmgduckQKb 5SnzwYkS_pZIx_JMx.GE0.Z2YckU8U7qR7Y770ufaJoGdzws4_Y0sJy55rMRrffOILPZWKsHLc8O jlwWNulNMpmpkgkI4VzJd3uml_zaeUmL5qPf2pu_A9z.rtHPPHIwh2rMD23FOFZeOJz0Pq1ujyg5 8oT.FStn5kEv8hN52FJWPic6bW8GmhM1lNk4CgIztFVk3YlyiPtmN0fk3wd9sXb.Pk5a75sJD2Ds vroz1h.YUHYlqfreZ69IP8gJCuChW6HmS.XQ.o1TQJwI_VEA4_aBxKjhWPq6l7sR6T2cz0qg3fuC yAkyOMOEXFkFTgph4mCuJJbkBNvhy4dgzxhg789DayZOAuIKleheXhC00_lOu3PPea5p5BMkE_PT mmWcQKuZUpbeYjV7aogYnFYchA4BI2V62ieUTEX1nSueFDCXQW_KnvUWgViIu3cdiTB0gVLUea8E njQkWlCZm5I69BCEN5v58jwlJlvTquz9jjX1J2BThz304_H88XTPVt5hlpVgXz1_CW4IHOoG_9D1 DVCDGZ.TjHMXVkZ0wwUMD6dCMrhOOtkHfU7O.pRjSTUa56k6PdrNl5ql6T6qnwpYq7E22M5QrFoc u3xWffmN5_RuQqVw6fCSa73v23omCuv1UFc5jHHht2imlUKmUeEWvuEeKkEXbwPsZLtqUwtjqKP3 USCcMwgHJ..NGSCsDzeoUXzUkEY1QzEGEAFFYdULaEEdqkOTzpyULGJqH_kQ9vxJuqPNRBfgAt4b L8f4w8Rr1WIaUeqpb0jbON_Tg6f1njr2iPX8oJOSN97XpjVwb.fZ376ezY2neahydJW9nLHc55r5 uklVBXmXPvlKPriom9KHS7yn41roCAEKL80K4sZxQT_YibaESqlzINj6zlRd6.rXJAEEeI48ZvDL 6R4t5WYXA6LbaZc9dZQJPj5wUTbhUqRlvp0gMxDCDaZTnnrMS_iUTDmR5DUew2CII1R4iiNVRVDH E6.vTDDZtpXO3MehOYbY5Uh4TSrkwXv.tblhcnaNnGkac_9VgG34ngSJ7sKgoKiOQYZu2B3ulrfJ EC.Bn_S_6XIHccPkMaYIpC1aJcVIpwXr11Foa7skNZzukPCVpxexHNl42bYoRZHvdYlVPdzRzVEA wAFuaYWP0sg6dMi40L2RNt3rlQnr44oYMAV49.yZY9MoY4DLA6.EIQfXXmdFKTGZ8fxRxsrCWv11 b9wehDulq5VaP8vSZEKWi1JzXIFqpV0pGborAGQ.Io.HSgch9D5i5jK1.WY0Jj_MAmy6tL9UYiiF W1p8S21HQcTb3U5BvMHyQcu2QQC0WUUGsd.c..89QDDUbRGkHMrj6Ap9MDNkCj9hyvtZmba.mRNf s X-Sonic-MF: X-Sonic-ID: 90383193-1432-4692-b60c-766a7a699096 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 13 Jan 2026 21:41:39 +0000 Received: by hermes--production-gq1-86969b76cd-xr9nr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 65d460a66ed8744bcb4acf85893415da; Tue, 13 Jan 2026 21:41:34 +0000 (UTC) Message-ID: <785b4793-29e7-419e-9713-57c2f99b1d17@yahoo.com> Date: Tue, 13 Jan 2026 13:41:32 -0800 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 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: Cedric Blancher , freebsd-hackers@freebsd.org References: Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.24866 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from] X-Rspamd-Queue-Id: 4drN4829NVz3Hv4 On 1/13/26 12:28, Cedric Blancher wrote: > On Mon, 12 Jan 2026 at 23:04, Rick Macklem wrote: >> >> On Mon, Jan 12, 2026 at 1:56 PM Rick Macklem wrote: >>> >>> On Mon, Jan 12, 2026 at 11:52 AM Cedric Blancher >>> wrote: >>>> >>>> Good evening! >>>> >>>> Does the FreeBSD >= 14.3 NFSv4.1 client and server support case >>>> insensitive filesystems, e.g. exported ZFS or FAT? >>> Greater than, as in 15.0. >> Oops, that's 15.1-> >> (I looked and it is in stable/15, but not releng/15.0.) >> (I work with main and the stable branches and don't keep track of when the >> releases branch off.) > > OK, version confusion. :) > > What do I have to do as FreeBSD root user to update a FreeBSD 15.0 > installation to a kernel version which supports case-insensitive > filesystems for NFSv4.2 server, i.e. FATTR4_CASE_INSENSITIVE and > FATTR4_CASE_PRESERVING are set according to the features of ZFS? > > Ced > > As I understand what Rick wrote: ) No *.*-RELEASE supports such. (No releng/*.* branch has such code.) ) Modern 15.0-STABLE supports such (stable/15 branch has such code). ) Modern 16.0-CURRENT supports such (main branch has such code). Are you in a situation that allows use of the likes of some commit of, say, 15.0-STABLE ( branch stable/15 )? If you must have a *.*-RELEASE instead, you have to wait for 15.1-RELEASE to be available. -- === Mark Millard marklmi at yahoo.com From nobody Tue Jan 13 22:48:15 2026 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 4drPYk6bhHz6Np8K for ; Tue, 13 Jan 2026 22:48:58 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4drPYk14Cnz3Qtq for ; Tue, 13 Jan 2026 22:48:58 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=eo3XPta3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cedric.blancher@gmail.com designates 2607:f8b0:4864:20::235 as permitted sender) smtp.mailfrom=cedric.blancher@gmail.com Received: by mail-oi1-x235.google.com with SMTP id 5614622812f47-45a85a05a70so1828469b6e.3 for ; Tue, 13 Jan 2026 14:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768344532; x=1768949332; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PugA6LgVFpSz066bxxOhnxJoHsTjPPruk7FB91Fpw6U=; b=eo3XPta34qvwwTMo/XCQgt5CTvDWG+pBorPeBgJ3QuOhGrwwBbxZNmV8jw6bgsJNbI AafHOGrhgZkhS0UMqNhfiKDr/rBfUVPqgRgXHUG9VB3QiOIDZ4z4VClSGQrHsl60F3Me mvjwnRj2CIK+YEvDC8Q6YZhX76N6tV0ZXFSClGuga3A1hgS/30nN5Xkhgj/nXPvb5Sli LObRrS6jsKzXMiDcDhSFtOK3I+NQCEkyqprCxNTskVHa0EXFH5Li641X0lqBc0kD3rUJ w6bu+ZQj3Rb5YowXZYNByHlCxVUxTs8HZ39NvKJuIf4dzwn1PM1uCp4HdiOgkjU17bWe +Psg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768344532; x=1768949332; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=PugA6LgVFpSz066bxxOhnxJoHsTjPPruk7FB91Fpw6U=; b=n3F9aTh6yLyhMzwvDJN1lDT+w0CG7v6rD/JfdgRB257QW5X6Vjhp27ga+hVKcqRNwQ n2RqH47/tfMdqdEfmYkTXqpvg3pnTFSJe6Mgi5U0QEPMXBatRU/3OevMMNx9v31cQCC7 V9UJvHjoEOEJT3UigNiTRlLe9cNr4fsc4zvabGA/8azWlkYD7UAus7hy1iGhAuho09CX aBbSQ74dc5YQWOIcHfkq0JRuLAIXHe4B46MPXrSF+1bPKSf2MtR2oYWpVQCPNDDAWBay feeD83iAr/nKuiNPv+H3yjTk72WfL6a90LSYvOdMvNAZmOMezy4OhzS1eWeOwyCWm7qw TOsA== X-Gm-Message-State: AOJu0YyjQbSgTE0lf1tZQ6j/EiyFq8xlk5QgorMYKa7oKl7XMC3jO+Wi eTtJISdxPVgtcri2uPtD61AU0ow2QVHV42Dr57IeBv9RElTJzFzsrB8TxWlJJ6oYrf7+QR6r2Mg Mk9emr9OSB0c9ueJsyju89hp/zXTgy1xSxZ6u X-Gm-Gg: AY/fxX4koUD+hXYVtksT3Z8LUflhmZmXjcSvrlZOdtwl7afojr2rCESeDiARR/eavJs 77nDdLmawp6Yr3GoJKgYKSQt6XrbcIBgT/9cQ+dgMk73dRhWVlfm/NNYH6DUaRyrqWUK0mM7+2N aWSYIbeLwHwegdoRbpM4VCWuBJTDK2EOL0iqA3OtAFXTptmv43PdYXrEyZwWgQuMAH6AMW2W6PE iEnIiRsCjuFioxwHVeVXfjWv/gHF5cS2kENprhDWVkeP5L/es4VBsjqAUjeuNPlZ7nakQ== X-Received: by 2002:a05:6808:c286:b0:450:b3a:539e with SMTP id 5614622812f47-45c73d65761mr77224b6e.28.1768344531890; Tue, 13 Jan 2026 14:48:51 -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: <785b4793-29e7-419e-9713-57c2f99b1d17@yahoo.com> In-Reply-To: <785b4793-29e7-419e-9713-57c2f99b1d17@yahoo.com> From: Cedric Blancher Date: Tue, 13 Jan 2026 23:48:15 +0100 X-Gm-Features: AZwV_QhuLJxbmMB9KK8gkmdrCxRIwGGKlTLRscDB1lBYXxkKZsaOQPSoMV0GKgQ Message-ID: Subject: Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: - X-Spamd-Result: default: False [-1.83 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_SPAM_SHORT(0.17)[0.171]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TAGGED_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::235:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4drPYk14Cnz3Qtq On Tue, 13 Jan 2026 at 22:41, Mark Millard wrote: > > On 1/13/26 12:28, Cedric Blancher wrote: > > On Mon, 12 Jan 2026 at 23:04, Rick Macklem wro= te: > >> > >> On Mon, Jan 12, 2026 at 1:56=E2=80=AFPM Rick Macklem wrote: > >>> > >>> On Mon, Jan 12, 2026 at 11:52=E2=80=AFAM Cedric Blancher > >>> wrote: > >>>> > >>>> Good evening! > >>>> > >>>> Does the FreeBSD >=3D 14.3 NFSv4.1 client and server support case > >>>> insensitive filesystems, e.g. exported ZFS or FAT? > >>> Greater than, as in 15.0. > >> Oops, that's 15.1-> > >> (I looked and it is in stable/15, but not releng/15.0.) > >> (I work with main and the stable branches and don't keep track of when= the > >> releases branch off.) > > > > OK, version confusion. :) > > > > What do I have to do as FreeBSD root user to update a FreeBSD 15.0 > > installation to a kernel version which supports case-insensitive > > filesystems for NFSv4.2 server, i.e. FATTR4_CASE_INSENSITIVE and > > FATTR4_CASE_PRESERVING are set according to the features of ZFS? > > > > Ced > > > > > > > As I understand what Rick wrote: > > ) No *.*-RELEASE supports such. (No releng/*.* branch has such code.) > > ) Modern 15.0-STABLE supports such (stable/15 branch has such code). > > ) Modern 16.0-CURRENT supports such (main branch has such code). > > Are you in a situation that allows use of the likes of some commit of, > say, 15.0-STABLE ( branch stable/15 )? > > If you must have a *.*-RELEASE instead, you have to wait for > 15.1-RELEASE to be available. OK, I have to do some outings: I am new to FreeBSD, and worse: I am management (sort of rond-de-cuir). What do I have to do as user root in a FreeBSD 15.0 installation to update to 15.0-STABLE to get working FATTR4_CASE_INSENSITIVE and FATTR4_CASE_PRESERVING support in FreeBSD NFS server? Also, which FreeBSD commit added support for working FATTR4_CASE_INSENSITIVE and FATTR4_CASE_PRESERVING? Ced --=20 Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur From nobody Tue Jan 13 23:17:22 2026 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 4drQBh38c7z6NqXN for ; Tue, 13 Jan 2026 23:17:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4drQBf5W98z3TYZ for ; Tue, 13 Jan 2026 23:17:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=dd8yWOy1; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768346246; bh=GDXhtStKUBy5UbCQCfbazRQiwSDZyAx3/3W/ftvhNIk=; h=Date:Subject:To:References:From:Cc:In-Reply-To:From:Subject:Reply-To; b=dd8yWOy1t437Jv6MC8pkEd4Feu4HjqsdI2wUNWvozOBi/iiIgCbrSk6K1FINP/JM99qTpLcCns5Tyrz2h7Aqy4EdtS0lGonFqUvci7gnUsNrSPzYVxumQmwp5lt6HKVn+s3Y4QlrAIzQOsIZl5+G3Em6KzqbDw2R6mO/A/VX/7tDu7tvNSt5cZXG4lsyEO+tlSSWTz7yeQ1pWy7KN1j/0CC4VFmYPSosAmlDNC8Gv1xnPyZG+FJciWwX9Gtx2CfLqEcuih7CC+16dDcUVddpZbBw0Lpq2Rv45pnKJPXV+OMK7Hf0DzPEGVTeJnIMNJOD05w1bjUoOs95e+ZUpEzcHw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768346246; bh=NPr3QPlJAe0GEBJh34ONgyw5ucWY5DRpG0Nf3n8zsF4=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=sM1YbnjXL9g+q5e92fUWRDeT1XsB58d0va2jzRk9Y02kc0rK7SmymRYBROU9plvOu+Q/MhoPP6/nbvyHJOIPNzTQvCCrKdPY47oZgn5RWguQnQoAo+0jjKCXSDdKDQWA7nZo5vEofChyJdGfZNANtPd+++WGuwbILbRHvOKkI3hNC1sXy4yY/dnzCMQp1qDk6lLrAbMPxdyWxR2dZrPAZcHEpe2LQ6Rc+1Re/5rfMracQPvr8WoffgU55Z71uHV6n4nBdtVMq+V2HdaZDzXn5FiJnVKT8FpKaGjnzUMSSqaX5d8e1R/W/mW7RjP/MdFGYV/mkqLapKb829hjxh5hog== X-YMail-OSG: 0BT95pEVM1nIP0oUtr_lpm7HvY1bvmE4LMCl0QI3sMoaqitfZxKB1nBUUwGqF9T CLlSdee.AgjXo6.6rplqiHStiAIO61tpbU3gTd6zFbiV26nRs2a.mOZX0VhygL4BzqQldURYIN9A yuqrowM40PMtlvDCH49U5MRi7nzqaxxjudWMq9vNEAteqO3eoEvZZOR9aazmPIf2aI9hBj9Wv6Je DFysXMq.gB41_.ewmR2ffcZ3eWX1khBrYMYOemSWzxB32p3od6RXHT946D8C67im10fe0H0ga78p 6T4KpvuYe1S1BSndi2D0hTRe7fIqmBbzJPNwnCTEcRRs1xBbdwSoh_F8SpoWq_T1xONSCNBpi8KT 9d9qJX8UVpqpFKHlocHbICTTqzQ0gGGonGB7PgSZfhCb4_.Il60zUicUS8VOdqW.5Z66wqSyjaCO 8Be8UZJ5hjBrMr1lyqj4cbP3ryFqqusV2ZFqQWH4sQK3XVE9vXkFCMaekimIpfmE7Goom.peMDsu ti_Yi0QwLCA98PfznNrmGbYtu_XBNxdBDbvP.gdXSniK1rmoKXlnUdKki7C4RRg0RXMvPDa034nu FFrLiUOnbRJPFE3eJfAJ1yIJ0XvhPH3YBAurM8hWDOeSmhbrHSsTGW0aLMYYLFcPuDhO0EWN4jdW JWQkOhUcFJYud9OFuhv23RL_TbwhK8W2kCC5QDXpwfADAma.z4bRvs3R2E6WFoy.m0u3LRy2KwUr 07qlaX_jRlLKw5zHh6mMlWAVx5lyt9hZK61EFxL0f7rVZyPjOHoXC71PJWm_Th5NGfZbrCaX7Bhf MbWYgzFkrb1JGTGhqkcFEvlz2bqDRiG2HTrSZDMxMGDTQzhDGWLW9VXDCZaxvl_nAIay2dGCbxYO .ZI1CKz0P0Zbq16L_pw9kAo.JCtRcO7G1aj6MDJe9Hrk9.0IfNRRTm6JXrJAicwbaD4xDnktm.BP kwvrV._3xvzDHIW.qwmeP2Px0HaLg_4FQFYKK91dRF1SM3s.cWDkesiEv8rO1U4B_fBpSr7mlimb 2DGcXSWEq32qfrbuhETEwbbxp4u4DE7UQkQrIfplZDmjuIP1EQEsxj6K3EqwsfOlwiHvPGQ4y.6Z qBKEQ5MG2GtdmpLjo_rIgUxS.rv2tszo23WxJhuwqAwpbPnfT6APBK0yhEeD29y9yEWr5hi_jDXW 2wNJxuAEQOfGOYmAuez01ucScTp3g32QqFQRDylR7KLjgIN_FlKCUOU.rQzxz8qe.yqbTcg.4CwE l0SAdn2gHHpjPTq8XN2ff2MV.cWHEvR6g3XzZiBUTbN3i9G8DflDjDxYrufgu3jxFYhcFSRPhbKl MsgCRTYbo4yKL9jGR5SHCt4DU_jK59AQ4ryL._DbzbaxxSiH.hlNlsxjNhISewL0Iv2BIwUnTL87 XQKyJxTrsS5panLM0QhxHtgtKUiQH6VAntY1poteU2fCfJR9IRflkhRJOFeKVuTsTwT4PA9hPfNj YsrAFkJSDX45oDKQjDU8gM4Get5XRKA_jKb2hCayGnsJAFOs27nQNQxIFsXIjG4wSaBbCaZUSa1a .wTXmZriuEnwz17P.y4XWS.8rJQPS.4qKvp8ajaaZP3mqGgfNC4hcV5BT2XzzMQb7O4G0IE0b86R kUZW1YuWiRJ9rZ0cFY6zvM88A0oRADnBUGKr_dFnaIG2iZkJglKUim704cCWd3L4L8V2CkduetMi QzAbXWmKO_ndZp8ZUdkdK4wAAh2vvCMlDxPaaJAmkcy8ZcseFbkZjoyElCkaH559ls95OPzl9CWB fdBvppkJkZyVE1gPXlvre5gSz01PXbKBEttjpuLVyCcXHdu10jzkeisoQ36pWTX131RJmzLNFFfQ 2zBLcWj9CAC2JMyGCbE_jh3QI0Jo93oUg9P2Uf3KlLFt6jexJf1qdhf3rHbMf1SiofoajPoGVxuL 8nPT3U0_5JKZ2.CczlBrhVgkSau6vu8Xg_iHq_h4HhfZc1ZtKv9zrmL4sAIeGtv34fT4MmIJ6ivl ry3nIX8R1a5o5jDE4dag43UGmKKrCIKOrOazb8IB8YOpQVDI8EjpsArhad7AO_XkoYrZlztmdP7H GJ65tfj4XNvM5gJ5g.hQv33YdAk41qoKJqMIg9dLxYonqERaTH92PM1C0CUy4rImgFTAEG3tBMqg _dJLfhqvJi9fDHyI5MBj5Xzw2tHsU_2p1N8cUNjRIQhPTI_9aM5xeaDI0JFI_enVyPhTG5A2fCmA FtV5c1O.jR9cZAvEacrPP7gx9ajXZDjuToUEv39BoJSsqf1.Zlk0N.F2znZp9mftMLRPH9HLaoS7 AdVUcAcrm X-Sonic-MF: X-Sonic-ID: ec5cccfa-c225-4241-8fe3-fd566aaa10a5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Tue, 13 Jan 2026 23:17:26 +0000 Received: by hermes--production-gq1-86969b76cd-fz94v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 66eeec1f29c3cc4584807f0cf8713179; Tue, 13 Jan 2026 23:17:22 +0000 (UTC) Message-ID: <748e57b4-1fca-4df3-b70f-605eedd4bb8b@yahoo.com> Date: Tue, 13 Jan 2026 15:17:22 -0800 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 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: Cedric Blancher , freebsd-hackers@freebsd.org References: <785b4793-29e7-419e-9713-57c2f99b1d17@yahoo.com> Content-Language: en-US From: Mark Millard Cc: Rick Macklem In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.24987 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.92 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.922]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.84:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from] X-Rspamd-Queue-Id: 4drQBf5W98z3TYZ On 1/13/26 14:48, Cedric Blancher wrote: > On Tue, 13 Jan 2026 at 22:41, Mark Millard wrote: >> >> On 1/13/26 12:28, Cedric Blancher wrote: >>> On Mon, 12 Jan 2026 at 23:04, Rick Macklem wrote: >>>> >>>> On Mon, Jan 12, 2026 at 1:56 PM Rick Macklem wrote: >>>>> >>>>> On Mon, Jan 12, 2026 at 11:52 AM Cedric Blancher >>>>> wrote: >>>>>> >>>>>> Good evening! >>>>>> >>>>>> Does the FreeBSD >= 14.3 NFSv4.1 client and server support case >>>>>> insensitive filesystems, e.g. exported ZFS or FAT? >>>>> Greater than, as in 15.0. >>>> Oops, that's 15.1-> >>>> (I looked and it is in stable/15, but not releng/15.0.) >>>> (I work with main and the stable branches and don't keep track of when the >>>> releases branch off.) >>> >>> OK, version confusion. :) >>> >>> What do I have to do as FreeBSD root user to update a FreeBSD 15.0 >>> installation to a kernel version which supports case-insensitive >>> filesystems for NFSv4.2 server, i.e. FATTR4_CASE_INSENSITIVE and >>> FATTR4_CASE_PRESERVING are set according to the features of ZFS? >>> >>> Ced >>> >>> >> >> >> As I understand what Rick wrote: >> >> ) No *.*-RELEASE supports such. (No releng/*.* branch has such code.) >> >> ) Modern 15.0-STABLE supports such (stable/15 branch has such code). >> >> ) Modern 16.0-CURRENT supports such (main branch has such code). >> >> Are you in a situation that allows use of the likes of some commit of, >> say, 15.0-STABLE ( branch stable/15 )? >> >> If you must have a *.*-RELEASE instead, you have to wait for >> 15.1-RELEASE to be available. > > OK, I have to do some outings: I am new to FreeBSD, and worse: I am > management (sort of rond-de-cuir). > > What do I have to do as user root in a FreeBSD 15.0 installation to > update to 15.0-STABLE to get working FATTR4_CASE_INSENSITIVE and > FATTR4_CASE_PRESERVING support in FreeBSD NFS server? My context has only ever had very simple configurations. But I do know that how to upgrade depends on which technique was used to install 15.0-RELEASE : If you have a installation based on the new pkgbase style of installation it would be different than if you had a installation via a historical technique. For the historical techniques (source code style installation vs. other historical styles of installation, for example), there is variability as well. You likely need to report various supporting information details describing the specific context that you would be starting from. Overall, I'm not likely to be an appropriate guide for any sort of production environment doing a FreeBSD OS upgrade, even with such information. > > Also, which FreeBSD commit added support for working > FATTR4_CASE_INSENSITIVE and FATTR4_CASE_PRESERVING? It is probably best if Rick answers the question about his own code. I've no knowledge of its details. That need not mean that he would be an proper source overall for how to upgrade the FreeBSD OS from 15.0-RELEASE to a vintage of 15.0-STABLE . -- === Mark Millard marklmi at yahoo.com From nobody Wed Jan 14 00:18:06 2026 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 4drRXx6PZdz6NtvK for ; Wed, 14 Jan 2026 00:18:25 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4drRXx4SSXz3ZR6 for ; Wed, 14 Jan 2026 00:18:25 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-652fdd043f9so2687529a12.1 for ; Tue, 13 Jan 2026 16:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768349899; x=1768954699; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HCq9NX2eBbS5dC59UlfYQHxsMFewwAx8ifFmcS95xNs=; b=Utk07siQIPlzunKyljJCoL17cGj5iUP73KTcCqkowuSBhMDrziVVxCToNybGifvKkn cE/eQVAwiUbXWpwAT3+lwZefaMI6UX46uFXsyKFB3arR0V2YM74lYozMpJFVYiBtyWeb PZeczPzUyiYDprSErYbQufXKBx4I8vN29Iu4gz2/PeWfG4DeIRYAGSayZzOv8OEH6kWZ dMpH/lATYSZepU3AM3Xx+dnAD0S8o2nmsnLVbkeORQ7nmH4+kXXsrMs3kGVLmnspwZsK RIrnui0bNTXkT0ZMsmDv58796YScFF4A/Q4uVOCqFIUabz/DPJj9xHpbfi6K4q8nq2K0 nQ2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768349899; x=1768954699; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=HCq9NX2eBbS5dC59UlfYQHxsMFewwAx8ifFmcS95xNs=; b=vo7JpDyTUGIMQBEpdhOYI/WZCfAqq7sxeSYqw+aqqFBM4bez23oFxgPpJO7g9vlrT4 MeGDqVrwHdU1aDXwwtYJ1G2dCHZ/ssM3/Ik3wWz/LfpIzlboXLPM+p2w3jJeGpXOfiaI Tz5qa3mWsRMeswqtghMU2SqJ3rik2xZKEP+gijWzln2bJtbMsEMGiqTqGG9ny1duk3r8 YPoACfSvJRkNZ5BfpM7O7HTx8bbBJAEKfRwqR4OjlGVZ84Hln1RpKh6HLa+W32OnjmK8 KhCJJYetOI7YdLjxMg4nXkDfjdieVeeE4MIg6kXRZglArPYjSVOeCU0sD4v9fbXRrzVi pRGA== X-Forwarded-Encrypted: i=1; AJvYcCVp6jkyN6BBHsGTOXYp7nRYZoI/8A0G7nXYwzTkX8BMuzcbHDjouDlIAyQWLc4oYdWeuZtlcQYCuoOqUgW0AI4=@freebsd.org X-Gm-Message-State: AOJu0YwD1XCEFppPLDyYAkjrs6l4Pxi9gGApmZYs4jMOEFziqSKl5Ye3 W0uRtQckEHzOnrrlZY8JevkmunpodaIGUpCX6O2rcRV65jrRhuMSuccI5gbXIK5VTAC6kpGfXzU 8/bx+17i5W6rIdMgHh09Q5zu4MVATgwc6WXQ= X-Gm-Gg: AY/fxX4hceuQmJD2nC4MC/rBZwvbEYE9g7/jyBcY6MfcG1AYNO7lts3mk/nni+EEY82 vR99vTB5xv0aDHhgHTtEQub62KuOST5CVmOlz1cItcWML2dTT0QV8e9uBSdEAP5fLQEz/cAyuTN jWpwsU1pbTHyLx9nRRjE3gKcVUhcuuEy1z2eGagoTvCK0g6q169fn3r1IwhHzIkkVuhwlxEHwYt N5TGDmnjI3d5gXKc4we4iESFoUVDsnTzqq9Zsn3MD6RonAmDuHX9UhVTlyWRocAkW79W1RmaFUJ QbYPSHz1jPy8zWBEPf7vuwybKKY= X-Received: by 2002:a05:6402:5204:b0:649:815e:3fac with SMTP id 4fb4d7f45d1cf-653ee1afb50mr254633a12.23.1768349899117; Tue, 13 Jan 2026 16:18:19 -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: <785b4793-29e7-419e-9713-57c2f99b1d17@yahoo.com> <748e57b4-1fca-4df3-b70f-605eedd4bb8b@yahoo.com> In-Reply-To: <748e57b4-1fca-4df3-b70f-605eedd4bb8b@yahoo.com> From: Rick Macklem Date: Tue, 13 Jan 2026 16:18:06 -0800 X-Gm-Features: AZwV_Qj8RQ3Ol_F81MIjeq7Awhq9Wm0KcF39ZWiXd0BFs0hgDpmcmbYMoH7OOTs Message-ID: Subject: Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: Mark Millard Cc: Cedric Blancher , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4drRXx4SSXz3ZR6 On Tue, Jan 13, 2026 at 3:17=E2=80=AFPM Mark Millard wr= ote: > > On 1/13/26 14:48, Cedric Blancher wrote: > > On Tue, 13 Jan 2026 at 22:41, Mark Millard wrote: > >> > >> On 1/13/26 12:28, Cedric Blancher wrote: > >>> On Mon, 12 Jan 2026 at 23:04, Rick Macklem w= rote: > >>>> > >>>> On Mon, Jan 12, 2026 at 1:56=E2=80=AFPM Rick Macklem wrote: > >>>>> > >>>>> On Mon, Jan 12, 2026 at 11:52=E2=80=AFAM Cedric Blancher > >>>>> wrote: > >>>>>> > >>>>>> Good evening! > >>>>>> > >>>>>> Does the FreeBSD >=3D 14.3 NFSv4.1 client and server support case > >>>>>> insensitive filesystems, e.g. exported ZFS or FAT? > >>>>> Greater than, as in 15.0. > >>>> Oops, that's 15.1-> > >>>> (I looked and it is in stable/15, but not releng/15.0.) > >>>> (I work with main and the stable branches and don't keep track of wh= en the > >>>> releases branch off.) > >>> > >>> OK, version confusion. :) > >>> > >>> What do I have to do as FreeBSD root user to update a FreeBSD 15.0 > >>> installation to a kernel version which supports case-insensitive > >>> filesystems for NFSv4.2 server, i.e. FATTR4_CASE_INSENSITIVE and > >>> FATTR4_CASE_PRESERVING are set according to the features of ZFS? > >>> > >>> Ced > >>> > >>> > >> > >> > >> As I understand what Rick wrote: > >> > >> ) No *.*-RELEASE supports such. (No releng/*.* branch has such code.) > >> > >> ) Modern 15.0-STABLE supports such (stable/15 branch has such code). > >> > >> ) Modern 16.0-CURRENT supports such (main branch has such code). > >> > >> Are you in a situation that allows use of the likes of some commit of, > >> say, 15.0-STABLE ( branch stable/15 )? > >> > >> If you must have a *.*-RELEASE instead, you have to wait for > >> 15.1-RELEASE to be available. > > > > OK, I have to do some outings: I am new to FreeBSD, and worse: I am > > management (sort of rond-de-cuir). > > > > What do I have to do as user root in a FreeBSD 15.0 installation to > > update to 15.0-STABLE to get working FATTR4_CASE_INSENSITIVE and > > FATTR4_CASE_PRESERVING support in FreeBSD NFS server? As Mark noted, you can either wait for the 15.1 release (April, maybe?) or you can set up a system from sources (aka stable/15). To do the latter for a test system (where maintaining it with up-to-date security patches, etc) is pretty straightforward. (To do so while maintaini= ng it will up-to-date security patches, etc, is outside my wheelhouse and probably yours. Companies like Netflix do this with "main" which is the newest greenest bits, but they have an engineering team to manage it.) For a simple test server, you could: - Install 15.0 using the "legacy .." (I can't remember what the install calls it exactly, but it is not the new pkg based installation.) - Download the stable/15 source tree.. # git clone https://git.freebsd.org src (Or https://github.com/freebsd/freebsd-src if the above doesn't work for you.) # git checkout stable/15 - cd into the top level directory (src for the above git example). # make buildkernel # make installkernel - There isn't any userland changes, so just replacing the kernel should be sufficient. # shutdown -r now To configure a ZFS file system for case insensitive, you need to first find out what your pool is called, if you do not know that. # zpool list - The name is the first field Now to create a file system that is case insensitive... # zfs create -o casesensitivity=3Dinsensitive / - If you messing around with a Windows client, you might also want.. # zfs set xattr=3Ddir / - To enable named attributes (alternate data streams). # zfs set aclinherit=3Dpassthrough / - Which has been said to be the best setting for acl inheritance for Windows clients. (There are also a couple of other properties that might be useful, but I have no experience with them. "normalization" and "aclmode" are two of them. Read "man zfsprops" for more info.) I have no idea if a pkg installed system can be upgraded via sources, but I do not see why replacing the kernel would be a problem, assuming it is just a test system and you do not need to track bugfixes... rick > > My context has only ever had very simple configurations. But I do know > that how to upgrade depends on which technique was used to install > 15.0-RELEASE : If you have a installation based on the new pkgbase style > of installation it would be different than if you had a installation via > a historical technique. For the historical techniques (source code style > installation vs. other historical styles of installation, for example), > there is variability as well. > > You likely need to report various supporting information details > describing the specific context that you would be starting from. > > Overall, I'm not likely to be an appropriate guide for any sort of > production environment doing a FreeBSD OS upgrade, even with such > information. > > > > > Also, which FreeBSD commit added support for working > > FATTR4_CASE_INSENSITIVE and FATTR4_CASE_PRESERVING? > > It is probably best if Rick answers the question about his own code. > I've no knowledge of its details. That need not mean that he would be an > proper source overall for how to upgrade the FreeBSD OS from > 15.0-RELEASE to a vintage of 15.0-STABLE . > > -- > =3D=3D=3D > Mark Millard > marklmi at yahoo.com From nobody Wed Jan 14 00:28:48 2026 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 4drRnC1r0Dz6NvMl for ; Wed, 14 Jan 2026 00:29:03 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4drRnB4TSXz3d8m for ; Wed, 14 Jan 2026 00:29:02 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=eGVPtEyh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-650854c473fso597983a12.1 for ; Tue, 13 Jan 2026 16:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768350541; x=1768955341; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=j002OKxBHH7MSTuCKPx0ZFjRNe7lzTj5Se/FVH7NEYE=; b=eGVPtEyhzY/mk2RMbvEpAOFa+X4OcPPJaoc0Pzfne8RHx0Ga7HdQhZ9NDmEgT33QII Tpc6rZIEfh+zO2NMfmERNLswYo/MYJoIyoq+Hal5uohXpC6KbtoO8hn8vj7v5rrBfOry 58uAsKnQhmXdvcDCstkDqRDIb6mk+1DwUL31eJ0Xwd3OEGl6JRjl/hRKcisF644vA1OG EdFuc0w2tW9YmQKInFoCll+GYtRr7RXPMewruzKgm6IAJiuFQzGxj5YrAs8/nEIdoRf1 hwh5XUeUUSphnJg7GaarXOwOxvQwleA959rA04ISC90Sv0DGJCfMPrengozyLu6blAry 0gmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768350541; x=1768955341; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=j002OKxBHH7MSTuCKPx0ZFjRNe7lzTj5Se/FVH7NEYE=; b=Ni8lfyGqoNGVx893W4C57wGQhJfDFYGGY4LeRQq6O4qonCDwwTc5iJfhU0BDkWDF52 7ydx7/Bhe8StRokPa6k8nx+7WZrUsD+ld39z+XVd+K+oH+pKtyOofa+2KXDWuFuBdJmM 007dSml74/KdtR7TSEMigsszc9EzMSerWD7R+dyrSMvHeZTvJJfzIFk/4azewLlfgxAw QnjGCVqb+OXSMyFWWmWCtPHY33A9LAFB76pOC6WCSompPF+VkhzipSkqFuJMdT1pPJRU iZQ+GEpYMGxvO61lNwgPVMGH6ApW1kqPGKudbDAyW8li3dl5A/Q0JC1dhikySV5rttey lbqQ== X-Forwarded-Encrypted: i=1; AJvYcCWc+MEQzoziW8ZiLoLxf1t2djw+30T/6ht44jLnmddlhZ2OpGQhNPiRo4KWZRHIk+QzUhS9rVc0qIQKvi+Fgro=@freebsd.org X-Gm-Message-State: AOJu0YzWzmlQqh37PxECEWoM+V98JComBx6z44mYLgMnsaY5aYS7k3Ie mjVcdTfe4rwjNjdDPITwsDZVAaKyCcGL1xV9nN2fdb+12P5LH6s03k0UfSJR5MAHsepx0nKFSCp 006BClbVEQzLf/EekBf+tnJ3Yqop8Uw== X-Gm-Gg: AY/fxX5yRbAx30W6qeZs5S8Y1scUBuFJ1tXP5wAbbLKNfmgodx4mOp3Fho0P7FTskMS x6PfcyfgAMxAN7fkLNBhlTZcKeLBfXFBw4aScDfMNhfoH/MA4AczQ2LgX3bRVLwnAzgokM/LNx8 49QlUvDKVvgQ6uWG2A7XVQlaaP215MhdeMeC9mqnM8JIjNcapYUdxeh0EPL1PTsme1lG3s1JDC1 vEe5gkUpHEBqA7cEPBIJctN7x16+OlIJJsHrsMtty3YwJE8b89d6Rcf2Dqf9gkncQ7r00Ya7aAZ fSVnM7ezaafc543c8ZXw0jsgcdY= X-Received: by 2002:a05:6402:1ed3:b0:64b:a3ea:5086 with SMTP id 4fb4d7f45d1cf-653ec0c2a8emr697017a12.12.1768350541205; Tue, 13 Jan 2026 16:29:01 -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: <785b4793-29e7-419e-9713-57c2f99b1d17@yahoo.com> <748e57b4-1fca-4df3-b70f-605eedd4bb8b@yahoo.com> In-Reply-To: From: Rick Macklem Date: Tue, 13 Jan 2026 16:28:48 -0800 X-Gm-Features: AZwV_QjtgCcnG8JlBwWc0F4RmiYOHkLSXYCPTL6W2iHrpxsWaIjEqRdtxBw9_aE Message-ID: Subject: Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: Mark Millard Cc: Cedric Blancher , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; TAGGED_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4drRnB4TSXz3d8m On Tue, Jan 13, 2026 at 4:18=E2=80=AFPM Rick Macklem wrote: > > On Tue, Jan 13, 2026 at 3:17=E2=80=AFPM Mark Millard = wrote: > > > > On 1/13/26 14:48, Cedric Blancher wrote: > > > On Tue, 13 Jan 2026 at 22:41, Mark Millard wrote: > > >> > > >> On 1/13/26 12:28, Cedric Blancher wrote: > > >>> On Mon, 12 Jan 2026 at 23:04, Rick Macklem = wrote: > > >>>> > > >>>> On Mon, Jan 12, 2026 at 1:56=E2=80=AFPM Rick Macklem wrote: > > >>>>> > > >>>>> On Mon, Jan 12, 2026 at 11:52=E2=80=AFAM Cedric Blancher > > >>>>> wrote: > > >>>>>> > > >>>>>> Good evening! > > >>>>>> > > >>>>>> Does the FreeBSD >=3D 14.3 NFSv4.1 client and server support cas= e > > >>>>>> insensitive filesystems, e.g. exported ZFS or FAT? > > >>>>> Greater than, as in 15.0. > > >>>> Oops, that's 15.1-> > > >>>> (I looked and it is in stable/15, but not releng/15.0.) > > >>>> (I work with main and the stable branches and don't keep track of = when the > > >>>> releases branch off.) > > >>> > > >>> OK, version confusion. :) > > >>> > > >>> What do I have to do as FreeBSD root user to update a FreeBSD 15.0 > > >>> installation to a kernel version which supports case-insensitive > > >>> filesystems for NFSv4.2 server, i.e. FATTR4_CASE_INSENSITIVE and > > >>> FATTR4_CASE_PRESERVING are set according to the features of ZFS? > > >>> > > >>> Ced > > >>> > > >>> > > >> > > >> > > >> As I understand what Rick wrote: > > >> > > >> ) No *.*-RELEASE supports such. (No releng/*.* branch has such code.= ) > > >> > > >> ) Modern 15.0-STABLE supports such (stable/15 branch has such code). > > >> > > >> ) Modern 16.0-CURRENT supports such (main branch has such code). > > >> > > >> Are you in a situation that allows use of the likes of some commit o= f, > > >> say, 15.0-STABLE ( branch stable/15 )? > > >> > > >> If you must have a *.*-RELEASE instead, you have to wait for > > >> 15.1-RELEASE to be available. > > > > > > OK, I have to do some outings: I am new to FreeBSD, and worse: I am > > > management (sort of rond-de-cuir). > > > > > > What do I have to do as user root in a FreeBSD 15.0 installation to > > > update to 15.0-STABLE to get working FATTR4_CASE_INSENSITIVE and > > > FATTR4_CASE_PRESERVING support in FreeBSD NFS server? > As Mark noted, you can either wait for the 15.1 release (April, maybe?) > or you can set up a system from sources (aka stable/15). > > To do the latter for a test system (where maintaining it with up-to-date > security patches, etc) is pretty straightforward. (To do so while maintai= ning > it will up-to-date security patches, etc, is outside my wheelhouse and > probably yours. Companies like Netflix do this with "main" which is the > newest greenest bits, but they have an engineering team to manage it.) > Oh, and if you are doing a fresh install, you can just download an install image for stable/15. I do it by going onto ftp.freebsd.org anonymous ftp cd'ng into "pub/FreeBSD/snapshots/ISO-IMAGES/15.0 get whichever one works for you. ("amd64" in the name is x86-64bits. disc1 in the name is a bootable DVD image. It used to have everything in it, but I'm not sure if it still does. If not, you'll need to have the system connected to the internet during the install. (I'll admit the recent change to the pkg based installation has completely confused me.;-) rick > For a simple test server, you could: > - Install 15.0 using the "legacy .." (I can't remember what the install > calls it exactly, but it is not the new pkg based installation.) > - Download the stable/15 source tree.. > # git clone https://git.freebsd.org src > (Or https://github.com/freebsd/freebsd-src if the above doesn't work > for you.) > # git checkout stable/15 > - cd into the top level directory (src for the above git example). > # make buildkernel > # make installkernel > - There isn't any userland changes, so just replacing the kernel > should be sufficient. > # shutdown -r now > > To configure a ZFS file system for case insensitive, you need to > first find out what your pool is called, if you do not know that. > # zpool list > - The name is the first field > Now to create a file system that is case insensitive... > # zfs create -o casesensitivity=3Dinsensitive / > - If you messing around with a Windows client, you might also want.. > # zfs set xattr=3Ddir / > - To enable named attributes (alternate data streams). > # zfs set aclinherit=3Dpassthrough / > - Which has been said to be the best setting for acl inheritance for > Windows clients. > (There are also a couple of other properties that might be useful, > but I have no experience with them. "normalization" and "aclmode" > are two of them. Read "man zfsprops" for more info.) > > I have no idea if a pkg installed system can be upgraded via > sources, but I do not see why replacing the kernel would be a > problem, assuming it is just a test system and you do not need > to track bugfixes... > > rick > > > > > My context has only ever had very simple configurations. But I do know > > that how to upgrade depends on which technique was used to install > > 15.0-RELEASE : If you have a installation based on the new pkgbase styl= e > > of installation it would be different than if you had a installation vi= a > > a historical technique. For the historical techniques (source code styl= e > > installation vs. other historical styles of installation, for example), > > there is variability as well. > > > > You likely need to report various supporting information details > > describing the specific context that you would be starting from. > > > > Overall, I'm not likely to be an appropriate guide for any sort of > > production environment doing a FreeBSD OS upgrade, even with such > > information. > > > > > > > > Also, which FreeBSD commit added support for working > > > FATTR4_CASE_INSENSITIVE and FATTR4_CASE_PRESERVING? > > > > It is probably best if Rick answers the question about his own code. > > I've no knowledge of its details. That need not mean that he would be a= n > > proper source overall for how to upgrade the FreeBSD OS from > > 15.0-RELEASE to a vintage of 15.0-STABLE . > > > > -- > > =3D=3D=3D > > Mark Millard > > marklmi at yahoo.com From nobody Wed Jan 14 01:01:44 2026 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 4drSW72pGSz6Nwjl for ; Wed, 14 Jan 2026 01:01:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4drSW51vdwz3jFL for ; Wed, 14 Jan 2026 01:01:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=U7YDLrOs; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768352508; bh=b7FPpriFjKkXlzoWxFV6BbLtg8d/iIbT3HTDQlnjxeo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=U7YDLrOsJDyKtDaRx7VlMw57W/DwTU9IBos+WRrJ/8m49UlzLxS7RGO10Ge02BuDADyRW/RtESrO2c5zcrxDO2r1oabLlXLweGmjJYLlWd//Dy71LyDFd4QtH/dNgugI8q0bmZ06jnv9fLPLxIZFlHYAjNP5i0cHP7dBeAsQSrnObqMHptud79OWB41Fdxn2kic8vjd4SWvAKwnDfJ1Kp8uAHrWWoiJWaKN7lbtbcjtYyzSOUNm826V91tu2Aiti46WUDihbaHxtP5/uDvy4IcE8+jRTqa3iyESs8hZDq8AYQn15dZh04rhQrVzWQOLYnMHPBvDFfNtp+V6san5pYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768352508; bh=oDlXuT4KXJQlwchNxP52FnU+LkqEKowyjQosyMedM6P=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=a2KUHs7quj6L3VryQWCJD7bv4hBNokzr3klOIgYxOxKlJxLg7mtjFRvky/RfV5i52smRr3fL3GXZ29QHXYd8oFa/PT40GVq2BfeO5dPkQlpOQc2/sARG8greoKqZXjeogNmPl0ob8lIybbb8Q6DsX5kyddMcbDGTC8g1qkeJuqInBbnbKmkHrD2Th/09TuUvZPPgCUVMWJaSSWLnKON1/eB1bzKLUO45iQB79kA1t71bPHXXBNEAlLMDnqLZEE1Zj2QzwRHa0gN5Ar5iqkCvqQEuSx0e9G55wEXegBZIWk/UndrI61TOENDugNH7Wo7ViLk2orK/U91EfPRBgbCQ6g== X-YMail-OSG: AL445F0VM1mseVCHaX44tVWvc3opz2H98E35AstgILkCoPkcLkr.goCLOAfoLmC I6HoENKPXtHgCfzJ.Fhq_57hYL4S90LUUaJxG8pVw_DPxXWl2c5N2XQ8Ow_MnriZgme4jfd0JzWB JIwp_5PKsIcPxnD6DilFk5umR2esACD_1RHrubnnhgqA4X_1D5bv.FgJdNCrrVwlDbTXw6vXeabP oGdgtk._a_L_YGk.YbSIUvyA.O0PTAetlYPCmapH4HSMlIegwvSDCMcS.RulbwKjOf4TmFcB9sHr SI5f5bpO02i.ekfQFt7rHWnIkluPEmZFvgXIkkSmQbjmcDAxU6natAs7TVzvB8ZXVq7ZSWIrzd.o BNW7XGKVcTGj76V5_eXyPTRSHnbWvBOYaBJUr6q.s5D1OMlCI4EkvxhmNUDK8TebciYNCbuYilbP _c1NmASKrlOuZJS7gBOQttT0HxirTAr283iZfeloiXUXTqlEGRwYhpeTdzGQUAke81pnAt0zgBF6 ltfaZgHMbvO5IoAgzS827Bmc2GQhyPOYOOP0VFF1pJngvTYQ7sKamZsBVKrVFsB.m5MZVshE0UMO MJHN6dRugAtZB6m0I53KXFVfDBL2pjwF.Kw7kov0a46zZfCpkBiPUWSDTL1DjilQMf4cr3kJUH4A X720qulXxu9KktxTu1xsFOsG85jQPr69XYFElEsBuOGrTuCLvUvIlHJS2PXED99trszOs6RCCeEw GLdtujQwpBXHub7ybKUm0mPj_l_mY0qjywkfaNpH45NIgy3UDU1hwa7JYxNOxmKKaiNHIS3mP4po u.7laIeyfYYbQ3yDm3G_.HdOxkp6rJT0P2eXKcqE6jV8keP4a3mKCPlrxC44ta.9V8hj0A85yj6x z52Hs3CZYzvceGxVeV5LRPlP1upE3pG1fYUnjQseVueLiy.F17MMzVlfnnF.JGYYrtwbWHNVu.9X PlgkzOlHh_iY5A7rZCxLMuDVpIwKJ8yUpuxc35BmgDxU_V8NhAdWrFD4.J1X9PCaZfKPB45nAWIY 2FaxMFbfFgS_eri00754A5bus1KsCJ9B4hsHFM3akh7feZKtgqVodcDxzS7inN6FDdV.w.oWaQqX xi0zQtdUzGNOFaGMIvyDeTQ7EuSDSkci18F.BiMxOVZHEXM0vx9JsQDrQ2gSA8luBNCMgyCgoOow .TVqZ7nzbJmUX_mvfo9gIJjl_UOBRPhpcuciqIv1ECBRiZQPeGNBrK8FHEQrn.jtAAF0cRhkk59H r2L1tLibvb1_nQFs3HXfQjhv4c7bsjfwtAKSjb6hvxLXf03qrBEBk_1bmSLo.IzLpcbSokf7hKMS lMhtqzGR8c0eIKSflpJp.DMfBw3.4Shw97U9zUI5YeFnuAY2XwQR402Y2T4bipzsT1I1.lhZcVCN AnWT5HiNDHhgch0u6MkMdrOoBn1lv6Gp4Gf0Dc4mRgp8PByK4kA.FX2CTITtkPo7x4rfgKPK1Co_ 317WwEKq1vI0tzYHdiZHdtgMAIP_3NmQbALPUkada773OZXlss58F_aO.6ZA6.yBI3lL2Pd701Ex nriQC4EqvdEUlFz4HA5MLVCj1y1dwGOAe0VtxHZBpwf5kb3khUE7nErKON2Zrjrj2r0B9XsZpimc jDcBrhmXuGNO942SMuSAY8r1JxjDZkCK2U_k1QdhbY5Nez_7S3tsdTvlggwtcazONvoxKvNcVFlH AY1Y8TGoMuijWh9ErjsGzoHPcxgVAm62gCI4j_flucWLg6QYj8TA3RRBKGqkozvSsJ1wUfuu2aP_ CI9GMBySZlcVOthqcvePBNmvsuIhey9PfijozMyHmNF.vtych3b_j8LqE.rqwZt0u.ZI0Mhsx8qa gjD05Toc04vJm9PdCfFKQQ9EqTtAjOkQKcvNWGXbtRPt_8rQJsm3I8o3nPxbU5NmMl9_2_A56o0z F5wTMLkzA3T5PCp4x5U11j3lUOmWm2Gw5Z8eX_JDX5QFMN60hZtxNXxZs1L85P5q_TbJbJEsnUXP eCDp_gCmkX1M3_iw7m5fN6WpaSNIiwndggK5cQFBNRxdnHCGKvCQ9J2LelqzGQrwXeXdMmZdhry9 4TgMRLEjOyH49X6CSnq0aYZ5IUjv5r2typS6ppfb38MwBWjQ.W.1gZXgHSFMWv1j8P4Vf0KaRUEk R2dPEqITDGvsv1hXRLpt2IYj7OkfSr5J8dvvWXRcIYaRodRVhnIayBGwG4SdxyKPIHjyTtBQiWev VJ7QDsvkCSRA58bKA4xhzPyrffl7IE4khVqY4TZKTzDnc0wsqjBp3Rt3n42o7MNbfpMQ2LihRGmy qt9I- X-Sonic-MF: X-Sonic-ID: 0f415890-0237-4125-9637-ebb1d069930e Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 14 Jan 2026 01:01:48 +0000 Received: by hermes--production-gq1-86969b76cd-f7q7z (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 71e87761ee61c5abf3db9a71862172c8; Wed, 14 Jan 2026 01:01:45 +0000 (UTC) Message-ID: <951afa00-1096-423b-9682-4a1a42b4487f@yahoo.com> Date: Tue, 13 Jan 2026 17:01:44 -0800 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 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: Cedric Blancher Cc: freebsd-hackers@freebsd.org, Rick Macklem References: <785b4793-29e7-419e-9713-57c2f99b1d17@yahoo.com> <748e57b4-1fca-4df3-b70f-605eedd4bb8b@yahoo.com> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.24987 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from] X-Rspamd-Queue-Id: 4drSW51vdwz3jFL On 1/13/26 16:18, Rick Macklem wrote: > On Tue, Jan 13, 2026 at 3:17 PM Mark Millard wrote: >> >> On 1/13/26 14:48, Cedric Blancher wrote: >>> On Tue, 13 Jan 2026 at 22:41, Mark Millard wrote: >>>> >>>> On 1/13/26 12:28, Cedric Blancher wrote: >>>>> On Mon, 12 Jan 2026 at 23:04, Rick Macklem wrote: >>>>>> >>>>>> On Mon, Jan 12, 2026 at 1:56 PM Rick Macklem wrote: >>>>>>> >>>>>>> On Mon, Jan 12, 2026 at 11:52 AM Cedric Blancher >>>>>>> wrote: >>>>>>>> >>>>>>>> Good evening! >>>>>>>> >>>>>>>> Does the FreeBSD >= 14.3 NFSv4.1 client and server support case >>>>>>>> insensitive filesystems, e.g. exported ZFS or FAT? >>>>>>> Greater than, as in 15.0. >>>>>> Oops, that's 15.1-> >>>>>> (I looked and it is in stable/15, but not releng/15.0.) >>>>>> (I work with main and the stable branches and don't keep track of when the >>>>>> releases branch off.) >>>>> >>>>> OK, version confusion. :) >>>>> >>>>> What do I have to do as FreeBSD root user to update a FreeBSD 15.0 >>>>> installation to a kernel version which supports case-insensitive >>>>> filesystems for NFSv4.2 server, i.e. FATTR4_CASE_INSENSITIVE and >>>>> FATTR4_CASE_PRESERVING are set according to the features of ZFS? >>>>> >>>>> Ced >>>>> >>>>> >>>> >>>> >>>> As I understand what Rick wrote: >>>> >>>> ) No *.*-RELEASE supports such. (No releng/*.* branch has such code.) >>>> >>>> ) Modern 15.0-STABLE supports such (stable/15 branch has such code). >>>> >>>> ) Modern 16.0-CURRENT supports such (main branch has such code). >>>> >>>> Are you in a situation that allows use of the likes of some commit of, >>>> say, 15.0-STABLE ( branch stable/15 )? >>>> >>>> If you must have a *.*-RELEASE instead, you have to wait for >>>> 15.1-RELEASE to be available. >>> >>> OK, I have to do some outings: I am new to FreeBSD, and worse: I am >>> management (sort of rond-de-cuir). >>> >>> What do I have to do as user root in a FreeBSD 15.0 installation to >>> update to 15.0-STABLE to get working FATTR4_CASE_INSENSITIVE and >>> FATTR4_CASE_PRESERVING support in FreeBSD NFS server? > As Mark noted, you can either wait for the 15.1 release (April, maybe?) > or you can set up a system from sources (aka stable/15). > > To do the latter for a test system (where maintaining it with up-to-date > security patches, etc) is pretty straightforward. (To do so while maintaining > it will up-to-date security patches, etc, is outside my wheelhouse and > probably yours. Companies like Netflix do this with "main" which is the > newest greenest bits, but they have an engineering team to manage it.) > > For a simple test server, you could: > - Install 15.0 using the "legacy .." (I can't remember what the install > calls it exactly, but it is not the new pkg based installation.) > - Download the stable/15 source tree.. > # git clone https://git.freebsd.org src > (Or https://github.com/freebsd/freebsd-src if the above doesn't work > for you.) > # git checkout stable/15 > - cd into the top level directory (src for the above git example). > # make buildkernel > # make installkernel > - There isn't any userland changes, so just replacing the kernel > should be sufficient. > # shutdown -r now By themselves, the above instructions are insufficient if you are trying to start from a pkgbase 15.0-RELEASE installation and upgrade to a 15.0-STABLE of some vintage, no matter if the intended end result is pkgbase vs. not. Using pkgbase going forward would have new binary releases of 15.0-STABLE available twice a day normally --but pkgbase has a Technology Preview status for its status for 15.0 and possibly for more 15.* . You may well not want to deal with such a status. 16.0-RELEASE should no longer have such a status for pkgbase. > > To configure a ZFS file system for case insensitive, you need to > first find out what your pool is called, if you do not know that. > # zpool list > - The name is the first field > Now to create a file system that is case insensitive... > # zfs create -o casesensitivity=insensitive / > - If you messing around with a Windows client, you might also want.. > # zfs set xattr=dir / > - To enable named attributes (alternate data streams). > # zfs set aclinherit=passthrough / > - Which has been said to be the best setting for acl inheritance for > Windows clients. > (There are also a couple of other properties that might be useful, > but I have no experience with them. "normalization" and "aclmode" > are two of them. Read "man zfsprops" for more info.) > > I have no idea if a pkg installed system can be upgraded via > sources, but I do not see why replacing the kernel would be a > problem, assuming it is just a test system and you do not need > to track bugfixes... It is possible to build and install and use alternate kernels under alternate names, leaving the official pkgbase ones alone. (pkgbase has code to validate official distribution materials have not been corrupted/changed.) I build such personal kernels from slightly alternate source code and boot mine sometimes and an official one other times. The boot-world is always an official pkgbase installation. (I also build alternate worlds that I install to directories and use via chroot and via being the world for some poudriere-devel jails. I use these when I'm booted with my personal kernel builds. But I can boot the system via just officially distributed materials for the boot-kernel and boot-world. My personal kernel builds work with the official pkgbase boot-world ok as well: I avoid such a kernel being based on older source code than any of the worlds were based on.) > > rick > >> >> My context has only ever had very simple configurations. But I do know >> that how to upgrade depends on which technique was used to install >> 15.0-RELEASE : If you have a installation based on the new pkgbase style >> of installation it would be different than if you had a installation via >> a historical technique. For the historical techniques (source code style >> installation vs. other historical styles of installation, for example), >> there is variability as well. >> >> You likely need to report various supporting information details >> describing the specific context that you would be starting from. >> >> Overall, I'm not likely to be an appropriate guide for any sort of >> production environment doing a FreeBSD OS upgrade, even with such >> information. >> >>> >>> Also, which FreeBSD commit added support for working >>> FATTR4_CASE_INSENSITIVE and FATTR4_CASE_PRESERVING? >> >> It is probably best if Rick answers the question about his own code. >> I've no knowledge of its details. That need not mean that he would be an >> proper source overall for how to upgrade the FreeBSD OS from >> 15.0-RELEASE to a vintage of 15.0-STABLE . >> >> -- >> === >> Mark Millard >> marklmi at yahoo.com > > -- === Mark Millard marklmi at yahoo.com From nobody Wed Jan 14 16:10:15 2026 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 4drrgM4HsMz6Nbn8 for ; Wed, 14 Jan 2026 16:10:23 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-10698.protonmail.ch (mail-10698.protonmail.ch [79.135.106.98]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4drrgL2Mfcz3DrY for ; Wed, 14 Jan 2026 16:10:22 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=proton.me header.s=protonmail header.b=mFoLtZrO; dmarc=pass (policy=quarantine) header.from=proton.me; spf=pass (mx1.freebsd.org: domain of minsoochoo0122@proton.me designates 79.135.106.98 as permitted sender) smtp.mailfrom=minsoochoo0122@proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1768407019; x=1768666219; bh=LH6armJbKn8GO16P/hu24jEjF6q3oB+br89+SoS7S7Q=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=mFoLtZrO3SBSgrLBoQ+QcN4V4zNGMKMF1r3lsWvZOXIPeMA/wlwplF6Adh6YjQ0zp njYAzch+rxI6vxbaIvnQy5zjCG5KVRsnGJmgrCvkLmZhSE2xH70Th0O3JFkByykpZb 8X8JgeSHaRVLhDjV0b4AYZrtA7AdV0QI7omjgdVZQ1ymWGK33U1FEsdqFHSuoGNw6l TRlXP+I0R/h/OmlDHstoeTAx5NHH18bGP0qaKT24A/QKLAbT0I/5w3ytvsDfrtSVJK bBH+Bk6MbJblsodEwbCI6TKc1AS1kVDRhQSNBkigVo6b8tyuQhf5Cwl+DihlnTNdwf v6WEuwIWkptjQ== Date: Wed, 14 Jan 2026 16:10:15 +0000 To: freebsd-hackers From: Minsoo Choo Subject: HMP scheduling on FreeBSD Message-ID: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 2ec480b1397534f18b3d95bc138cef1e02cf05b1 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 Content-Type: multipart/alternative; boundary="b1=_LVCc9dWVgGXxfDETeL60bHourcSyixQMsDxQJmnbQkk" X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.29 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[proton.me,quarantine]; RWL_MAILSPIKE_EXCELLENT(-0.40)[79.135.106.98:from]; R_SPF_ALLOW(-0.20)[+ip4:79.135.106.0/24:c]; R_DKIM_ALLOW(-0.20)[proton.me:s=protonmail]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:62371, ipnet:79.135.106.0/24, country:CH]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[79.135.106.98:from]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[proton.me:+] X-Rspamd-Queue-Id: 4drrgL2Mfcz3DrY --b1=_LVCc9dWVgGXxfDETeL60bHourcSyixQMsDxQJmnbQkk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 R3JlZXRpbmdzLAoKRm9yIHRoZSBsYXN0IGZldyBkYXlzLCBJJ3ZlIGJlZW4gd29ya2luZyBvbiBz Y2hlZHVsZXIgb3B0aW1pemF0aW9uIGZvciBoZXRlcm9nZW5lb3VzIGNvcmVzICgiSE1QIHNjaGVk dWxpbmciIGZyb20gbm93IG9uKSBvbiBGcmVlQlNELiBBZnRlciBkYXlzIG9mIHJlYWRpbmcgc3Bl Y3MsIHBsYW5uaW5nIHN0cnVjdHVyZSwgYW5kIHdyaXRpbmcgY29kZSwgSSBjYW1lIHRvIGEgbW9k ZWwgdGhhdCBjYW4gYmUgdXRpbGl6ZWQgZm9yIGltcGxlbWVudGluZyBITVAgc2NoZWR1bGluZy4g SSBvcGVuZWQgYSBmaXJzdCByZXZpc2lvbiBvbiBQaGFicmljYXRvciAoRDU0Njc0KSBhIGZldyBk YXlzIGFnbyBidXQgZGVjaWRlZCB0byBpbnRyb2R1Y2UgdGhpcyBtb2RlbCBpbiB0aGUgbWFpbGlu ZyBsaXN0IGFuZCBoZWFyIG90aGVycycgb3BpbmlvbnMuCgpGaXJzdCBvZiBhbGwsIEhNUC1yZWxh dGVkIGNvZGUgKHNjaGVkdWxpbmcsIHByb3ZpZGVyLCBjcHVjYXAgZnJhbWV3b3JrLCBldGMpIGFy ZSBvbmx5IGJ1aWx0IGFuZCBlbmFibGVkIHdoZW4gIm9wdGlvbnMgSE1QIiBpcyBzcGVjaWZpZWQg aW4ga2VybmVsIGNvbmZpZ3VyYXRpb24uIE9mIGNvdXJzZSwgdGhpcyBzaG91bGRuJ3QgYmUgYWN0 aXZhdGVkIGJ5IGRlZmF1bHQgYmVjYXVzZSBpdCdzIGluIGV4cGVyaW1lbnQgc3RhdHVzLiAib3B0 aW9ucyBITVAiIHNob3VsZCBiZSBhZGRlZCB0byBrZXJuZWwgY29uZmlndXJhdGlvbiB0byBlbmFi bGUgdGhpcyBmZWF0dXJlZCBhbmQgdGhpcyB3b24ndCBiZSBlbmFibGVkIGJ5IGRlZmF1bHQgdW50 aWwgdGhlIG1ham9yaXR5IG9mIGRldmVsb3BlcnMgYmVsaWV2ZSB0aGF0IEhNUCBzY2hlZHVsaW5n IGlzIHN0YWJpbGl6ZWQuCgpUaGUgZmlyc3QgY29tcG9uZW50IG9mIEhNUCBzY2hlZHVsaW5nIGlz ICJjcHVjYXAiLiBPbmUgaXNzdWUgd2l0aCBITVAgc2NoZWR1bGluZyBpcyB0aGF0IGlkZW50aWZ5 aW5nIHRoZSBjYXBhY2l0eSBhbmQgc2NvcmVzIG9mIGEgcHJvY2Vzc29yIChpLmUuIHByb3ZpZGVy cykgaXMgbWFjaGluZS1kZXBlbmRlbnQgd2hpbGUgdGhlIHNjaGVkdWxlciBjb2RlIHNob3VsZCBi ZSBtYWNoaW5lLWluZGVwZW5kZW50LCBzbyBjcHVjYXAgYWN0cyBhcyBhbiBpbnRlcmZhY2UgYmV0 d2VlbiB0aGUgc2NoZWR1bGVyIGFuZCBwcm92aWRlcnMuIENQVSBjYXBhY2l0eSBhbmQgc2NvcmVz IGFyZSBzdG9yZWQgaW4gcGNwdSBzdHJ1Y3R1cmUgd2hpbGUgdGhlIG1hY2hpbmUncyBjcHVjYXAg c3RhdHVzIChlLmcuIGluaXRpYWxpemVkLCBoYXMgZHluYW1pYyBzY29yZXMsIGV0YykgaXMgc3Rv cmVkIGluIGdsb2JhbCBjcHVjYXAgc3RydWN0dXJlIG9mIHR5cGUgImNwdWNhcF90Ii4gSXQgYWxz byBpbmNsdWRlcyBmdW5jdGlvbnMgZm9yIHNjaGVkdWxlciBhbmQgcHJvdmlkZXJzLCBzdWNoIGFz IGFjY2Vzc29ycywgc2V0dGVycywgZmluZGluZyAiYmVzdCIgY3B1LCBldGMuIFRoZSByZXZpZXcg KEQ1NDY3NCkgYWRkcyB0aGVzZSBmYWNpbGl0aWVzIHVuZGVyIEhNUCBvcHRpb24uCgpXaGF0IGFy ZSBjYXBhY2l0eSBhbmQgc2NvcmVzPyBDYXBhY2l0eSBkZXNjcmliZXMgY3B1J3MgaGV0ZXJvZ2Vu ZWl0eSAobW9yZSBpbmZvcm1hdGlvbiBpbiBzeXMvY29udHJpYi9kZXZpY2UtdHJlZS9CaW5kaW5n cy9jcHUvY3B1LWNhcGFjaXR5LnR4dCkuIFRoaXMgaXMgc3RhdGljOyBpdCBpcyBpbml0aWFsaXpl ZCBvbiBib290IHRpbWUgKGUuZy4gZnJvbSBkZXZpY2UgdHJlZSkgYW5kIHN0b3JlZCBpbiBwY19j YXBfY2FwYWNpdHkgaW4gcGNwdSBhZnRlciBiZWluZyBub3JtYWxpemVkIHRvIDAtMTAyNC4gSWYg aXQgaXMgbm90IHByb3ZpZGVkLCB0aGUgZGVmYXVsdCB2YWx1ZSBvZiAxMDI0IHdpbGwgYmUgdXNl ZC4gSXQgaXMgc3RhdGljIGFuZCBjb3JlIHNwZWNpZmljOyBpZiBhIHBlcmZvcm1hbmNlIGNvcmUg aGFzIGNhcGFjaXR5IG9mIDEwMjQgYW5kIGEgZWZmaWNpZW5jeSBjb3JlIGhhcyBjYXBhY2l0eSBv ZiA2MDAsIHRoaXMgbWVhbnMgYWxsIHBlcmZvcm1hbmNlIGNvcmVzIGhhdmUgMTAyNCBhbmQgYWxs IGVmZmljaWVuY3kgY29yZXMgaGF2ZSA2MDAsIGFuZCB3aGV0aGVyIHRoZXkgYXJlIHRocm90dGxl ZCBvciBub3QsIHRoaXMgaW5mb3JtYXRpb24gc3RheXMgdGhlIHNhbWUuIEZvciB0aGlzIG5hdHVy ZSwgY2FwYWNpdHkgaXMgaGludCBmb3IgbG9hZGluZyBiYWxhbmNpbmcuIEJ5IGRpdmlkaW5nIGEg Y29yZSdzIGNhcGFjaXR5IGJ5IHRvdGFsIGNhcGFjaXR5LCB3ZSBjYW4gYXNzaWduIGFuIGVxdWFs IGZyYWN0aW9uIG9mIHRhc2tzIHRvIHRoZSBjb3JlJ3MgcnVuIHF1ZXVlLiBUaGVzZSBjcHVjYXAg aW5mb3JtYXRpb24sIGluY2x1ZGluZyBlbmFibGVtZW50IHN0YXR1cywgaGFzIGR5bmFtaWMgc2Nv cmUsIGluZGl2aWR1YWwgY2FwYWNpdHkgYW5kIHNjb3JlcywgY2FuIGJlIHF1ZXJpZWQgdXNpbmcg c3lzY3RsLgoKT24gdGhlIG90aGVyIGhhbmQsIHNjb3JlcyByZWZsZWN0IHRoZSByZWFsIHRpbWUg c3RhdHVzIG9mIGEgcHJvY2Vzc29yIGFuZCBhcmUgbm9ybWFsaXplZCB0byAwLTEwMjQuIFByb3Zp ZGVycyBsaWtlIEludGVsIFRocmVhZCBEaXJlY3RvciBnaXZlIHRoZSBjdXJyZW50IHN0YXR1cyBv ZiBlYWNoIGNvcmUgYW5kIGZlZWQgaXQgdG8gcGNfY2FwX3Njb3JlcyBpbiBwY3B1LiBTY29yZXMg YXJlIHVzZWQgZm9yIHRocmVhZCBzZWxlY3Rpb24uIEZvciBleGFtcGxlLCBpZiBhIHBlcmZvcm1h bmNlIGNvcmUgaXMgZXhwZXJpZW5jaW5nIHRocm90dGxpbmcsIGl0cyBzY29yZSBjb3VsZCBnbyBk b3duIHRvIDEwMDAuIEluIHRoYXQgY2FzZSwgdGhlIHNjaGVkdWxlciB3aWxsIHByZWZlciBjb3Jl IHRoYXQgaGFzIHRoZSBoaWdoZXN0IHNjb3JlLiBTY29yZXMgYXJlIGNvbXBsZXRlbHkgb3B0aW9u YWwgYmVjYXVzZSBtYW55IHByb2Nlc3NvcnMgZG8gbm90IHByb3ZpZGUgdGhpcywgYW5kIHdoZW4g c2NvcmUgaW5mb3JtYXRpb24gaXMgYWJzZW50LCBjcHVjYXAgZmFsbCBiYWNrcyB0byBjYXBhY2l0 eS4gU2luY2Ugc2NvcmVzIGFyZSBkeW5hbWljLCB0aGV5IGFyZSByZXRyaWV2ZWQgYW5kIHNldCB1 c2luZyBhdG9taWMgb3BlcmF0aW9ucy4KClByb3ZpZGVycyBmZWVkIGNhcGFjaXR5IG9yIHNjb3Jl IGluZm9ybWF0aW9uIHRvIGNwdWNhcC4gQ2FwYWNpdHkgcHJvdmlkZXJzIHN1Y2ggYXMgZGV2aWNl IHRyZWVzIGFuZCBBQ1BJIENQUEMgcnVuIG9uIGJvb3QgdGltZSBhbmQgZmVlZCBjYXBhY2l0eSBp bmZvcm1hdGlvbi4gSWYgdGhlcmUgaXMgbm8gY2FwYWNpdHkgcHJvdmlkZXIsIChhZ2FpbikgdGhl IGRlZmF1bHQgdmFsdWUgaXMgdXNlZC4gU2NvcmUgcHJvdmlkZXJzIHN1Y2ggYXMgSW50ZWwgSVRE IGFyZSBpbXBsZW1lbnRlZCBhcyBkZXZpY2UgZHJpdmVycy4gV2UgaGFkIElURCBpbXBsZW1lbnRh dGlvbiBwYXRjaCAoRDQ0NDUzLUQ0NDQ1OSkgYmFjayBpbiBNYXkgMjAyNCBjYWxsZWQgY29yZWRp cmVjdG9yLCBidXQgaXQgd2FzIG5lZ2xlY3RlZC4gV2l0aCBzb21lIG1vZGlmaWNhdGlvbiwgdGhp cyBjYW4gYmUgdGhlIGZpcnN0IGNwdWNhcCBwcm92aWRlci4gUHJvdmlkZXJzIGNhbm5vdCBiZSBs b2FkZWQgb3IgdW5sb2FkZWQgb24gcnVudGltZS4gQW4gZXhjZXB0aW9uIGlzIEFybSBTQ01JIHdo aWNoIGRvZXNuJ3QgZmVlZCBpbmZvcm1hdGlvbiB0byBjcHVjYXAsIGJ1dCBpbnN0ZWFkLCB0aGUg c2NoZWR1bGVyIHNob3VsZCBjb250cm9sIGFuZCByZXF1ZXN0IENQVSdzIHBlcmZvcm1hbmNlLgoK QmVmb3JlIGludGVncmF0aW5nIHNjaGVkdWxlciBhbmQgY3B1Y2FwLCBJIG5lZWQgdG8gZ28gdGhy b3VnaCBzY2hlZF91bGUuY+KAiyBmcm9tIHRvcCB0byBib3R0b20uIEFmdGVyIHRoYXQsIEknbGwg YWRkIG5ldyBmdW5jdGlvbnMgb3IgZHJvcCBleGlzdGluZyBvbmVzIGZyb20gdGhlIGNwdWNhcCBm cmFtZXdvcmsgdGhlbiB3b3JrIG9uIHRoZSBpbnRlZ3JhdGlvbi4KCklmIGFueW9uZSBpcyBpbnRl cmVzdGVkIGluIHRoaXMgaW1wbGVtZW50YXRpb24sIHBsZWFzZSByZXBseSB0byB0aGlzIHRocmVh ZCBhbmQvb3IgcmV2aWV3IG15IGNwdWNhcCBwYXRjaCBhdCBENTQ2NzQuCgpNaW5zb28= --b1=_LVCc9dWVgGXxfDETeL60bHourcSyixQMsDxQJmnbQkk Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5HcmVldGluZ3MsPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5Gb3IgdGhlIGxhc3QgZmV3 IGRheXMsIEkndmUgYmVlbiB3b3JraW5nIG9uIHNjaGVkdWxlciBvcHRpbWl6YXRpb24gZm9yIGhl dGVyb2dlbmVvdXMgY29yZXMgKCJITVAgc2NoZWR1bGluZyIgZnJvbSBub3cgb24pIG9uIEZyZWVC U0QuIEFmdGVyIGRheXMgb2YgcmVhZGluZyBzcGVjcywgcGxhbm5pbmcgc3RydWN0dXJlLCBhbmQg d3JpdGluZyBjb2RlLCBJIGNhbWUgdG8gYSBtb2RlbCB0aGF0IGNhbiBiZSB1dGlsaXplZCBmb3Ig aW1wbGVtZW50aW5nIEhNUCBzY2hlZHVsaW5nLiBJIG9wZW5lZCBhIGZpcnN0IHJldmlzaW9uIG9u IFBoYWJyaWNhdG9yIChENTQ2NzQpIGEgZmV3IGRheXMgYWdvIGJ1dCBkZWNpZGVkIHRvIGludHJv ZHVjZSB0aGlzIG1vZGVsIGluIHRoZSBtYWlsaW5nIGxpc3QgYW5kIGhlYXIgb3RoZXJzJyBvcGlu aW9ucy48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWws IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkZpcnN0IG9mIGFsbCwgSE1QLXJlbGF0ZWQg Y29kZSAoc2NoZWR1bGluZywgcHJvdmlkZXIsIGNwdWNhcCBmcmFtZXdvcmssIGV0YykgYXJlIG9u bHkgYnVpbHQgYW5kIGVuYWJsZWQgd2hlbiAib3B0aW9ucyBITVAiIGlzIHNwZWNpZmllZCBpbiBr ZXJuZWwgY29uZmlndXJhdGlvbi4gT2YgY291cnNlLCB0aGlzIHNob3VsZG4ndCBiZSBhY3RpdmF0 ZWQgYnkgZGVmYXVsdCBiZWNhdXNlIGl0J3MgaW4gZXhwZXJpbWVudCBzdGF0dXMuICJvcHRpb25z IEhNUCIgc2hvdWxkIGJlIGFkZGVkIHRvIGtlcm5lbCBjb25maWd1cmF0aW9uIHRvIGVuYWJsZSB0 aGlzIGZlYXR1cmVkIGFuZCB0aGlzIHdvbid0IGJlIGVuYWJsZWQgYnkgZGVmYXVsdCB1bnRpbCB0 aGUgbWFqb3JpdHkgb2YgZGV2ZWxvcGVycyBiZWxpZXZlIHRoYXQgSE1QIHNjaGVkdWxpbmcgaXMg c3RhYmlsaXplZC48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPlRoZSBmaXJzdCBjb21wb25lbnQg b2YgSE1QIHNjaGVkdWxpbmcgaXMgImNwdWNhcCIuIE9uZSBpc3N1ZSB3aXRoIEhNUCBzY2hlZHVs aW5nIGlzIHRoYXQgaWRlbnRpZnlpbmcgdGhlIGNhcGFjaXR5IGFuZCBzY29yZXMgb2YgYSBwcm9j ZXNzb3IgKGkuZS4gcHJvdmlkZXJzKSBpcyBtYWNoaW5lLWRlcGVuZGVudCB3aGlsZSB0aGUgc2No ZWR1bGVyIGNvZGUgc2hvdWxkIGJlIG1hY2hpbmUtaW5kZXBlbmRlbnQsIHNvIGNwdWNhcCBhY3Rz IGFzIGFuIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBzY2hlZHVsZXIgYW5kIHByb3ZpZGVycy4gQ1BV IGNhcGFjaXR5IGFuZCBzY29yZXMgYXJlIHN0b3JlZCBpbiBwY3B1IHN0cnVjdHVyZSB3aGlsZSB0 aGUgbWFjaGluZSdzIGNwdWNhcCBzdGF0dXMgKGUuZy4gaW5pdGlhbGl6ZWQsIGhhcyBkeW5hbWlj IHNjb3JlcywgZXRjKSBpcyBzdG9yZWQgaW4gZ2xvYmFsIGNwdWNhcCBzdHJ1Y3R1cmUgb2YgdHlw ZSAiY3B1Y2FwX3QiLiBJdCBhbHNvIGluY2x1ZGVzIGZ1bmN0aW9ucyBmb3Igc2NoZWR1bGVyIGFu ZCBwcm92aWRlcnMsIHN1Y2ggYXMgYWNjZXNzb3JzLCBzZXR0ZXJzLCBmaW5kaW5nICJiZXN0IiBj cHUsIGV0Yy4mbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyI+VGhlIHJldmlldyAoRDU0Njc0KSBhZGRzIHRoZXNlIGZhY2lsaXRpZXMgdW5kZXIgSE1QIG9w dGlvbi48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl cmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5XaGF0IGFyZSBjYXBhY2l0eSBh bmQgc2NvcmVzPyBDYXBhY2l0eSBkZXNjcmliZXMgY3B1J3MgaGV0ZXJvZ2VuZWl0eSAobW9yZSBp bmZvcm1hdGlvbiBpbiBzeXMvY29udHJpYi9kZXZpY2UtdHJlZS9CaW5kaW5ncy9jcHUvY3B1LWNh cGFjaXR5LnR4dCkuIFRoaXMgaXMgc3RhdGljOyBpdCBpcyBpbml0aWFsaXplZCBvbiBib290IHRp bWUgKGUuZy4gZnJvbSBkZXZpY2UgdHJlZSkgYW5kIHN0b3JlZCBpbiBwY19jYXBfY2FwYWNpdHkg aW4gcGNwdSBhZnRlciBiZWluZyBub3JtYWxpemVkIHRvIDAtMTAyNC4gSWYgaXQgaXMgbm90IHBy b3ZpZGVkLCB0aGUgZGVmYXVsdCB2YWx1ZSBvZiAxMDI0IHdpbGwgYmUgdXNlZC4gSXQgaXMgc3Rh dGljIGFuZCBjb3JlIHNwZWNpZmljOyBpZiBhIHBlcmZvcm1hbmNlIGNvcmUgaGFzIGNhcGFjaXR5 IG9mIDEwMjQgYW5kIGEgZWZmaWNpZW5jeSBjb3JlIGhhcyBjYXBhY2l0eSBvZiA2MDAsIHRoaXMg bWVhbnMgYWxsIHBlcmZvcm1hbmNlIGNvcmVzIGhhdmUgMTAyNCBhbmQgYWxsIGVmZmljaWVuY3kg Y29yZXMgaGF2ZSA2MDAsIGFuZCB3aGV0aGVyIHRoZXkgYXJlIHRocm90dGxlZCBvciBub3QsIHRo aXMgaW5mb3JtYXRpb24gc3RheXMgdGhlIHNhbWUuIEZvciB0aGlzIG5hdHVyZSwgY2FwYWNpdHkg aXMgaGludCBmb3IgbG9hZGluZyBiYWxhbmNpbmcuIEJ5IGRpdmlkaW5nIGEgY29yZSdzIGNhcGFj aXR5IGJ5IHRvdGFsIGNhcGFjaXR5LCB3ZSBjYW4gYXNzaWduIGFuIGVxdWFsIGZyYWN0aW9uIG9m IHRhc2tzIHRvIHRoZSBjb3JlJ3MgcnVuIHF1ZXVlLiBUaGVzZSBjcHVjYXAgaW5mb3JtYXRpb24s IGluY2x1ZGluZyBlbmFibGVtZW50IHN0YXR1cywgaGFzIGR5bmFtaWMgc2NvcmUsIGluZGl2aWR1 YWwgY2FwYWNpdHkgYW5kIHNjb3JlcywgY2FuIGJlIHF1ZXJpZWQgdXNpbmcgc3lzY3RsLjwvZGl2 PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+T24gdGhlIG90aGVyIGhhbmQsIHNjb3JlcyByZWZsZWN0IHRo ZSByZWFsIHRpbWUgc3RhdHVzIG9mIGEgcHJvY2Vzc29yIGFuZCBhcmUgbm9ybWFsaXplZCB0byAw LTEwMjQuIFByb3ZpZGVycyBsaWtlIEludGVsIFRocmVhZCBEaXJlY3RvciBnaXZlIHRoZSBjdXJy ZW50IHN0YXR1cyBvZiBlYWNoIGNvcmUgYW5kIGZlZWQgaXQgdG8gcGNfY2FwX3Njb3JlcyBpbiBw Y3B1LiBTY29yZXMgYXJlIHVzZWQgZm9yIHRocmVhZCBzZWxlY3Rpb24uIEZvciBleGFtcGxlLCBp ZiBhIHBlcmZvcm1hbmNlIGNvcmUgaXMgZXhwZXJpZW5jaW5nIHRocm90dGxpbmcsIGl0cyBzY29y ZSBjb3VsZCBnbyBkb3duIHRvIDEwMDAuIEluIHRoYXQgY2FzZSwgdGhlIHNjaGVkdWxlciB3aWxs IHByZWZlciBjb3JlIHRoYXQgaGFzIHRoZSBoaWdoZXN0IHNjb3JlLiBTY29yZXMgYXJlIGNvbXBs ZXRlbHkgb3B0aW9uYWwgYmVjYXVzZSBtYW55IHByb2Nlc3NvcnMgZG8gbm90IHByb3ZpZGUgdGhp cywgYW5kIHdoZW4gc2NvcmUgaW5mb3JtYXRpb24gaXMgYWJzZW50LCBjcHVjYXAgZmFsbCBiYWNr cyB0byBjYXBhY2l0eS4gU2luY2Ugc2NvcmVzIGFyZSBkeW5hbWljLCB0aGV5IGFyZSByZXRyaWV2 ZWQgYW5kIHNldCB1c2luZyBhdG9taWMgb3BlcmF0aW9ucy48L2Rpdj48ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRw eDsiPlByb3ZpZGVycyBmZWVkIGNhcGFjaXR5IG9yIHNjb3JlIGluZm9ybWF0aW9uIHRvIGNwdWNh cC4gQ2FwYWNpdHkgcHJvdmlkZXJzIHN1Y2ggYXMgZGV2aWNlIHRyZWVzIGFuZCBBQ1BJIENQUEMg cnVuIG9uIGJvb3QgdGltZSBhbmQgZmVlZCBjYXBhY2l0eSBpbmZvcm1hdGlvbi4gSWYgdGhlcmUg aXMgbm8gY2FwYWNpdHkgcHJvdmlkZXIsIChhZ2FpbikgdGhlIGRlZmF1bHQgdmFsdWUgaXMgdXNl ZC4gU2NvcmUgcHJvdmlkZXJzIHN1Y2ggYXMgSW50ZWwgSVREIGFyZSBpbXBsZW1lbnRlZCBhcyBk ZXZpY2UgZHJpdmVycy4gV2UgaGFkIElURCBpbXBsZW1lbnRhdGlvbiBwYXRjaCA8c3BhbiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+KDwvc3Bhbj48c3BhbiBzdHlsZT0i c2Nyb2xsYmFyLXdpZHRoOnRoaW47dGV4dC1kZWNvcmF0aW9uLWxpbmU6bm9uZTt0ZXh0LWRlY29y YXRpb24tdGhpY2tuZXNzOmF1dG87dGV4dC1kZWNvcmF0aW9uLXN0eWxlOnNvbGlkIj5ENDQ0NTMt RDQ0NDU5KSZuYnNwOzwvc3Bhbj5iYWNrIGluIE1heSAyMDI0IGNhbGxlZCBjb3JlZGlyZWN0b3I8 c3Bhbj4sIGJ1dCBpdCB3YXMgbmVnbGVjdGVkLiBXaXRoIHNvbWUgbW9kaWZpY2F0aW9uLCB0aGlz IGNhbiBiZSB0aGUgZmlyc3QgY3B1Y2FwIHByb3ZpZGVyLiBQcm92aWRlcnMgY2Fubm90IGJlIGxv YWRlZCBvciB1bmxvYWRlZCBvbiBydW50aW1lLiBBbiBleGNlcHRpb24gaXMgQXJtIFNDTUkgd2hp Y2gmbmJzcDs8c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+ZG9l c24ndCBmZWVkIGluZm9ybWF0aW9uIHRvIGNwdWNhcCwgYnV0IGluc3RlYWQsJm5ic3A7PC9zcGFu PnRoZSBzY2hlZHVsZXIgc2hvdWxkIGNvbnRyb2wgYW5kIHJlcXVlc3QgQ1BVJ3MgcGVyZm9ybWFu Y2UuPC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+PHNwYW4+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkJlZm9yZSBp bnRlZ3JhdGluZyBzY2hlZHVsZXIgYW5kIGNwdWNhcCwgSSBuZWVkIHRvIGdvIHRocm91Z2ggPGNv ZGU+c2NoZWRfdWxlLmM8L2NvZGU+4oCLIGZyb20gdG9wIHRvIGJvdHRvbS4gQWZ0ZXIgdGhhdCwg SSdsbCBhZGQgbmV3IGZ1bmN0aW9ucyBvciBkcm9wIGV4aXN0aW5nIG9uZXMgZnJvbSB0aGUgY3B1 Y2FwIGZyYW1ld29yayB0aGVuIHdvcmsgb24gdGhlIGludGVncmF0aW9uLjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+PGJy PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyI+SWYgYW55b25lIGlzIGludGVyZXN0ZWQgaW4gdGhpcyBpbXBsZW1lbnRhdGlv biwgcGxlYXNlIHJlcGx5IHRvIHRoaXMgdGhyZWFkIGFuZC9vciByZXZpZXcgbXkgY3B1Y2FwIHBh dGNoIGF0IEQ1NDY3NC48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPk1pbnNvbzwvZGl2PjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyIg Y2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrIj4NCjwvZGl2Pg0K --b1=_LVCc9dWVgGXxfDETeL60bHourcSyixQMsDxQJmnbQkk-- From nobody Wed Jan 14 20:47:04 2026 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 4dryq44fRwz6Nv3B for ; Wed, 14 Jan 2026 20:47:28 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gid2.gid.co.uk (ns0.gid.co.uk [IPv6:2001:470:94de::240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gid2.gid.co.uk", Issuer "gid2.gid.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dryq36dljz46DD for ; Wed, 14 Jan 2026 20:47:27 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by gid2.gid.co.uk (8.15.2/8.15.2) with ESMTP id 60EKlJ0w041355; Wed, 14 Jan 2026 20:47:19 GMT (envelope-from rb@gid.co.uk) Received: from smtpclient.apple ([194.32.164.24]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 60EKlE26009780; Wed, 14 Jan 2026 20:47:14 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3826.700.81.1.4\)) Subject: Re: HMP scheduling on FreeBSD From: Bob Bishop In-Reply-To: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> Date: Wed, 14 Jan 2026 20:47:04 +0000 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <1409C1C2-8843-464E-9491-44E840904C27@gid.co.uk> References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> To: Minsoo Choo X-Mailer: Apple Mail (2.3826.700.81.1.4) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dryq36dljz46DD HI, > On 14 Jan 2026, at 16:10, Minsoo Choo = wrote: >=20 > Greetings, >=20 > For the last few days, I've been working on scheduler optimization for = heterogeneous cores ("HMP scheduling" from now on) on FreeBSD. [etc] If you haven=E2=80=99t already, I strongly suggest reviewing this: = https://lists.freebsd.org/archives/freebsd-hackers/2023-March/001970.html and there may be other wisdom in that thread. -- Bob Bishop rb@gid.co.uk From nobody Wed Jan 14 22:14:52 2026 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 4ds0m51qqzz6P0bg for ; Wed, 14 Jan 2026 22:15:01 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ds0m512mqz3J7h; Wed, 14 Jan 2026 22:15:01 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1768428901; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v0uKXjGl2Zrtxq2GYXxsI0dKMCY2D69Ma3cZenB84xk=; b=b4fG3aEoIB0mHAq3XefaE/47rkIDkvorZYQgy6gQWsllafNbfWu57SMBkvLK/IgNWDZIem BM06nuxTnX8PvCItx/WRkDyx/S2DPZgZ0kDIQDmCQVcZTiEB5ctMmLQEuk1EsGhK6tVoUG SRceASl+n1T+x0GDSotrzDeUfvCcmiHn3YNdiIg4OUHiBhwBq2h8d1QU2zrEXuPLDOB6Kz rBiYp7BXe2TKy6HgwTfPU3N9wu/xVZ/Krg4Va5nI8t7KFJb5g/6ZJz35atFs3cXNzte+p1 /ZHz7WVlCr+qXUwV/0Zi4BtLyXysNTEGlrv/EzNJE3HBJVavcpiFjzTC+mHyBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1768428901; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v0uKXjGl2Zrtxq2GYXxsI0dKMCY2D69Ma3cZenB84xk=; b=SdVZxv2ADexmX4ZEzg6e42LSGPR0/RcQTPE+7GL7Vr4fl4F6fQ8LPBfdqWdyy4wvDMS95b s7d7hHe5siyKJvSWKJSSRi8JtByW8oxRIdK3AVFYLYeWZvrIpxNNOnxVvB7E9yNYI6OWuA VInlk4THdGFbbDTzTKAYeOdKMX/HaqhGaoFEV00R+64+M38zs6iRu0JeVQjKoPsyBi44XJ Mrzhb61kgNegxQ5k3YvaPn6nbRWxGWa3v21fCkrsMkVz/1dqgJzLAoM1zf1pOc7Me6Z0e3 SMnOrXLbmo+HzHPWq0CMwsFNOALOlAyBY8uihM1u56iPVjUSWq3veyK+qLDDFw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1768428901; a=rsa-sha256; cv=none; b=W70lADf9JlGz5eLxY95gjdmaY/WgA8r7OpY/x+vs+S7HNWvPbZCg7GNFgxL+Wl74msayi7 oZkSWBNIGI1qMxXai6sd9eaxm5wU7Bq9pqV2kWIYLc2Go0Ff68TvuCBKZxLHZ6T5lekIm2 zrcmjXdoO3qqlzdDv7xBqKnPMW0qiff5wBjCiYuvTvt3uhRpEr+p9Mrwc7gMTpmC25StXL P6Nd0yM9FX0hPizWYIe+e7V+jVHw3YMV8u9x4Pk+hiuOjBmt/LPyTzsL5xELkm+xTsM/Sd l81zNqbZKzyXOfXXQlEp62Fgv1Inbgh4nQtOjC+Wz8I4+zF2JMx+W2vGRIKEVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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) (Authenticated sender: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ds0m457MQz17xL; Wed, 14 Jan 2026 22:15:00 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Minsoo Choo Cc: freebsd-hackers Subject: Re: HMP scheduling on FreeBSD Date: Wed, 14 Jan 2026 23:14:52 +0100 Message-ID: <1886427.OVFmXjEfDW@ravel> In-Reply-To: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> 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 Content-Type: multipart/signed; boundary="nextPart7040536.qJWK8QVVMX"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart7040536.qJWK8QVVMX Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner To: Minsoo Choo Cc: freebsd-hackers Subject: Re: HMP scheduling on FreeBSD Date: Wed, 14 Jan 2026 23:14:52 +0100 Message-ID: <1886427.OVFmXjEfDW@ravel> MIME-Version: 1.0 Hi Minsoo, > For the last few days, I've been working on scheduler optimization for he= terogeneous cores ("HMP scheduling" from now on) on FreeBSD. That's great! I've also been working on it, albeit in a slow fashion and m= ostly in the background, rather focusing on scheduler design and integratio= n on our cpusets. Giving quickly some first comments. > The first component of HMP scheduling is "cpucap". One issue with HMP sch= eduling is that identifying the capacity and scores of a processor (i.e. pr= oviders) is machine-dependent while the scheduler code should be machine-in= dependent, so cpucap acts as an interface between the scheduler and provide= rs. CPU capacity and scores are stored in pcpu structure while the machine'= s cpucap status (e.g. initialized, has dynamic scores, etc) is stored in gl= obal cpucap structure of type "cpucap_t". It also includes functions for sc= heduler and providers, such as accessors, setters, finding "best" cpu, etc.= The review (D54674) adds these facilities under HMP option. I'll review D54674, but not in the immediate. Hopefully next week. =20 > By dividing a core's capacity by total capacity, we can assign an equal f= raction of tasks to the core's run queue. > > On the other hand, scores reflect the real time status of a processor (sn= ip). For example, if a performance core is experiencing throttling, its sco= re could go down to 1000. In that case, the scheduler will prefer core that= has the highest score. These are good first observations but they can only really apply in specifi= c circumstances. Converting core's capacity in run queue length can only d= rive a loaded system, not a mostly idle one. This mechanism will also caus= e an increase in latency for threads running on performant cores. There are several theoretical considerations that should be met *together*,= such as fairness, latency, bias to performance or to energy (policy), affi= nity, cpusets (directives), etc., and... > Before integrating scheduler and cpucap, I need to go through sched_ule.c= =E2=80=8B from top to bottom. After that, I'll add new functions or drop ex= isting ones from the cpucap framework then work on the integration. =2E..there are some practical considerations too. ULE maintains per-CPU ru= n queues and does inter-CPU thread exchange relatively infrequently (throug= h the so-called "long-term long balancer") for fairness. It will not excha= nge two threads on two different cores if there are the only ones running, = which again is unfair if the two cores have different performances. A general scheduler must cater to a variety of workloads, and it can be qui= te difficult to improve some characteristics without degrading others. We = certainly don't want to rush things. I invite you to read the https://wiki.freebsd.org/Scheduler/Hybrid for a gl= impse on some of the trade-offs involved and a wider perspective, which how= ever is by no means complete and for which input from you and any other int= erested parties is welcome. Thanks and regards. =2D-=20 Olivier Certner --nextPart7040536.qJWK8QVVMX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAmloFV0ACgkQjKEwQJce JidsGBAAtVD3WCKqZrowiBZng4d4lgjPXKy+2gh5O9if/fNP4PZG2kGDLACXO1WE yGMdM6kR5ykCgHfMaFTmS3P9ekeo0154aHiboueOnreEcJKcE1g4FbhKgyrshlKt NUUrhancmCSAOpWtvrc/zR2x/vqaQdV/9OgM3mJyLdGIvup4j6hr9EswcgLntrit kMiJgvbKkEGu7HwU0QeFpAnI+wvbP/VdW/4e2e/OqGUVyXvI93gOdjvcuRMnJz/E fHWJ1ca11WXjClZiRlSj1ZJGbvs9omFflJF4iiyw+o577+xAQgwyd04Jt4wVXRaP 4sPn3V3z1VWfnzmtp+wlg/YyDQ3U0FiU5qtG4MyRoq7+FdXKavyN+58qqP0hP0f0 8wBCK3YLssAW/Y8tRFWPAw6boynToUibf6XSdCaktVgLrYdvaHNYpNBqV9U8w/pb Vgp1EZxvM5ypIP8l7BlasGVe9nJ6Ona+oK3dF1oWBuAM2eUza4Udn/MdDNx3W9xI JTyXfQ/OjlMoUk3Xoqs9UFDjHxtpD2DifovsylvJGiWmEKHBgdXE61Dnoa1Mbp7q Azq0ndB00vkL7mvS98frEw+eYh2dLU/mYzN031/l07uKPFqpICh3XgmURDrQ1c0u oBp24yUmZYuNqF+d2O5IGvZTQf5F0HQ7kpFfFNR9IxKGrScEXj8= =NqLo -----END PGP SIGNATURE----- --nextPart7040536.qJWK8QVVMX-- From nobody Wed Jan 14 22:22:30 2026 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 4ds0ww0KGYz6P0kY for ; Wed, 14 Jan 2026 22:22:40 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo75.interia.pl (smtpo75.interia.pl [217.74.67.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ds0wv3sJWz3KCM for ; Wed, 14 Jan 2026 22:22:39 +0000 (UTC) (envelope-from vermaden@interia.pl) Authentication-Results: mx1.freebsd.org; none Date: Wed, 14 Jan 2026 23:22:30 +0100 From: vermaden Subject: Re: HMP scheduling on FreeBSD To: Minsoo Choo , freebsd-hackers X-Mailer: interia.pl/pf09 In-Reply-To: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> X-Originating-IP: 45.148.42.20 Message-Id: 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 Content-Type: multipart/alternative; boundary="=-qYugoi0WV8X4mxSZBSyM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=dk; t=1768429352; bh=2Cxru1X2vUtGGVykHGGVLP1cIsHhGgYERzzZKgXWOA0=; h=Date:From:Subject:To:Message-Id:MIME-Version:Content-Type; b=H7U9upbK+S5ttTj7nwLFPprfGkQ0Z3DXSBX7OnZBNwUzAbzmatJf/J6xgtfNM7HH5 Pe3lwuZhb/qGKv0yQPV/a3g6PXsOYxLewC0Ao6NYmJndZpkOaCRqHBTZEqLCi5+ieb F1T/VcZJditYpvAEL1/vYZHVMBTr5YErn7dWqPFs= X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16138, ipnet:217.74.64.0/22, country:PL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4ds0wv3sJWz3KCM --=-qYugoi0WV8X4mxSZBSyM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,one may also think about adding rc.conf(5) settings like:    s= ched_fast=3D"postgres nginx"    sched_slow=3D"cron at zfs-scrub"T= o force using faster or slower cores for various tasks.Regards,vermadenTema= t: HMP scheduling on FreeBSDData: 2026-01-14 17:10Nadawca: "Minsoo Choo" &l= t;minsoochoo0122@proton.me>Adresat: "freebsd-hackers" <freebsd-hacker= s@freebsd.org>; Greetings,For the last few days, I've been working on sc= heduler optimization for heterogeneous cores ("HMP scheduling" from now on)= on FreeBSD. After days of reading specs, planning structure, and writing c= ode, I came to a model that can be utilized for implementing HMP scheduling= . I opened a first revision on Phabricator (D54674) a few days ago but deci= ded to introduce this model in the mailing list and hear others' opinions.F= irst of all, HMP-related code (scheduling, provider, cpucap framework, etc)= are only built and enabled when "options HMP" is specified in kernel confi= guration. Of course, this shouldn't be activated by default because it's in= experiment status. "options HMP" should be added to kernel configuration t= o enable this featured and this won't be enabled by default until the major= ity of developers believe that HMP scheduling is stabilized.The first compo= nent of HMP scheduling is "cpucap". One issue with HMP scheduling is that i= dentifying the capacity and scores of a processor (i.e. providers) is machi= ne-dependent while the scheduler code should be machine-independent, so cpu= cap acts as an interface between the scheduler and providers. CPU capacity = and scores are stored in pcpu structure while the machine's cpucap status (= e.g. initialized, has dynamic scores, etc) is stored in global cpucap struc= ture of type "cpucap_t". It also includes functions for scheduler and provi= ders, such as accessors, setters, finding "best" cpu, etc. The review = (D54674) adds these facilities under HMP option.What are capacity and score= s? Capacity describes cpu's heterogeneity (more information in sys/contrib/= device-tree/Bindings/cpu/cpu-capacity.txt). This is static; it is initializ= ed on boot time (e.g. from device tree) and stored in pc_cap_capacity in pc= pu after being normalized to 0-1024. If it is not provided, the default val= ue of 1024 will be used. It is static and core specific; if a performance c= ore has capacity of 1024 and a efficiency core has capacity of 600, this me= ans all performance cores have 1024 and all efficiency cores have 600, and = whether they are throttled or not, this information stays the same. For thi= s nature, capacity is hint for loading balancing. By dividing a core's capa= city by total capacity, we can assign an equal fraction of tasks to the cor= e's run queue. These cpucap information, including enablement status, has d= ynamic score, individual capacity and scores, can be queried using sysctl.O= n the other hand, scores reflect the real time status of a processor and ar= e normalized to 0-1024. Providers like Intel Thread Director give the curre= nt status of each core and feed it to pc_cap_scores in pcpu. Scores are use= d for thread selection. For example, if a performance core is experiencing = throttling, its score could go down to 1000. In that case, the scheduler wi= ll prefer core that has the highest score. Scores are completely optional b= ecause many processors do not provide this, and when score information is a= bsent, cpucap fall backs to capacity. Since scores are dynamic, they are re= trieved and set using atomic operations.Providers feed capacity or score in= formation to cpucap. Capacity providers such as device trees and ACPI CPPC = run on boot time and feed capacity information. If there is no capacity pro= vider, (again) the default value is used. Score providers such as Intel ITD= are implemented as device drivers. We had ITD implementation patch (D44453= -D44459) back in May 2024 called coredirector, but it was neglected. W= ith some modification, this can be the first cpucap provider. Providers can= not be loaded or unloaded on runtime. An exception is Arm SCMI which d= oesn't feed information to cpucap, but instead, the scheduler should c= ontrol and request CPU's performance.Before integrating scheduler and cpuca= p, I need to go through sched_ule.c=E2=80=8B from top to bottom. After that= , I'll add new functions or drop existing ones from the cpucap framework th= en work on the integration.If anyone is interested in this implementation, = please reply to this thread and/or review my cpucap patch at D54674.Minsoo&= nbsp; --=-qYugoi0WV8X4mxSZBSyM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

one may also think about adding rc.conf(5) settings like:

=C2=A0 = =C2=A0 sched_fast=3D"postgres nginx"
=C2=A0 =C2=A0 sched_slow=3D"cron at= zfs-scrub"

To force using faster or slower cores for various tasks.=

Regards,
vermaden




Temat: HMP scheduling on FreeBSD
Data: 2026-01-14 17:10
Nadawca: "= Minsoo Choo" <minsoochoo0122@proton.me>
Adresat: "freebsd-hackers"= <freebsd-hackers@freebsd.org>;



Greetings,


First of all, HMP-related code (scheduling, prov= ider, cpucap framework, etc) are only built and enabled when "options HMP" = is specified in kernel configuration. Of course, this shouldn't be activate= d by default because it's in experiment status. "options HMP" should be add= ed to kernel configuration to enable this featured and this won't be enable= d by default until the majority of developers believe that HMP scheduling i= s stabilized.

The fir= st component of HMP scheduling is "cpucap". One issue with HMP scheduling i= s that identifying the capacity and scores of a processor (i.e. providers) = is machine-dependent while the scheduler code should be machine-independent= , so cpucap acts as an interface between the scheduler and providers. CPU c= apacity and scores are stored in pcpu structure while the machine's cpucap = status (e.g. initialized, has dynamic scores, etc) is stored in global cpuc= ap structure of type "cpucap_t". It also includes functions for scheduler a= nd providers, such as accessors, setters, finding "best" cpu, etc.=C2=A0The review (D54674) adds these facili= ties under HMP option.

What are capacity and scores? Capacity describes cpu's heterogenei= ty (more information in sys/contrib/device-tree/Bindings/cpu/cpu-capacity.t= xt). This is static; it is initialized on boot time (e.g. from device tree)= and stored in pc_cap_capacity in pcpu after being normalized to 0-1024. If= it is not provided, the default value of 1024 will be used. It is static a= nd core specific; if a performance core has capacity of 1024 and a efficien= cy core has capacity of 600, this means all performance cores have 1024 and= all efficiency cores have 600, and whether they are throttled or not, this= information stays the same. For this nature, capacity is hint for loading = balancing. By dividing a core's capacity by total capacity, we can assign a= n equal fraction of tasks to the core's run queue. These cpucap information= , including enablement status, has dynamic score, individual capacity and s= cores, can be queried using sysctl.

On the other hand, scores reflect the real time status of a = processor and are normalized to 0-1024. Providers like Intel Thread Directo= r give the current status of each core and feed it to pc_cap_scores in pcpu= . Scores are used for thread selection. For example, if a performance core = is experiencing throttling, its score could go down to 1000. In that case, = the scheduler will prefer core that has the highest score. Scores are compl= etely optional because many processors do not provide this, and when score = information is absent, cpucap fall backs to capacity. Since scores are dyna= mic, they are retrieved and set using atomic operations.

Providers feed capacity or score inform= ation to cpucap. Capacity providers such as device trees and ACPI CPPC run = on boot time and feed capacity information. If there is no capacity provide= r, (again) the default value is used. Score providers such as Intel ITD are= implemented as device drivers. We had ITD implementation patch (D44453-D44459)=C2=A0back in May 2024 called coredirector, but it wa= s neglected. With some modification, this can be the first cpucap provider.= Providers cannot be loaded or unloaded on runtime. An exception is Arm SCM= I which=C2=A0doesn't feed informat= ion to cpucap, but instead,=C2=A0the scheduler should control and re= quest CPU's performance.

Before integrating scheduler and cpucap, I need to go through sch= ed_ule.c=E2=80=8B from top to bottom. After that, I'll add new funct= ions or drop existing ones from the cpucap framework then work on the integ= ration.

<= /div>
If anyone is = interested in this implementation, please reply to this thread and/or revie= w my cpucap patch at D54674.

Minsoo
=C2=A0


--=-qYugoi0WV8X4mxSZBSyM-- From nobody Wed Jan 14 23:34:50 2026 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 4ds2XT3RmBz6P4LB for ; Wed, 14 Jan 2026 23:35:05 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4ds2XS4kmpz3QdP; Wed, 14 Jan 2026 23:35:03 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from delta.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 60ENYo3G049201; Thu, 15 Jan 2026 08:34:53 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1768433693; bh=HWvGFKQUgT8kNw8RQl5xChnogB/ZiRanLwjIPO3oCXA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=m1O+yHjFFxOCpGvQ9DscaEZ2LJlFRlzZHVZj04xwP9w/NjOyJhcmJuYrp6zzNNxv9 ydM1cmiE1yk0vskD/ZLcq3gw7Ax0mx8fOgvqbv5lBbUaWZAW9D+v4Wt1aSC2mO5jAd jCPQP2+9VulsBd8WBPxHTIvJoW1vnAN30933EQx4= Date: Thu, 15 Jan 2026 08:34:50 +0900 From: Tomoaki AOKI To: Olivier Certner Cc: Minsoo Choo , freebsd-hackers Subject: Re: HMP scheduling on FreeBSD Message-Id: <20260115083450.f20c13f24d2ebbc68db9cd01@dec.sakura.ne.jp> In-Reply-To: <1886427.OVFmXjEfDW@ravel> References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <1886427.OVFmXjEfDW@ravel> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4ds2XS4kmpz3QdP On Wed, 14 Jan 2026 23:14:52 +0100 Olivier Certner wrote: > Hi Minsoo, > > > For the last few days, I've been working on scheduler optimization for heterogeneous cores ("HMP scheduling" from now on) on FreeBSD. > > That's great! I've also been working on it, albeit in a slow fashion and mostly in the background, rather focusing on scheduler design and integration on our cpusets. > > Giving quickly some first comments. > > > The first component of HMP scheduling is "cpucap". One issue with HMP scheduling is that identifying the capacity and scores of a processor (i.e. providers) is machine-dependent while the scheduler code should be machine-independent, so cpucap acts as an interface between the scheduler and providers. CPU capacity and scores are stored in pcpu structure while the machine's cpucap status (e.g. initialized, has dynamic scores, etc) is stored in global cpucap structure of type "cpucap_t". It also includes functions for scheduler and providers, such as accessors, setters, finding "best" cpu, etc. The review (D54674) adds these facilities under HMP option. > > I'll review D54674, but not in the immediate. Hopefully next week. > > > By dividing a core's capacity by total capacity, we can assign an equal fraction of tasks to the core's run queue. > > > > On the other hand, scores reflect the real time status of a processor (snip). For example, if a performance core is experiencing throttling, its score could go down to 1000. In that case, the scheduler will prefer core that has the highest score. > > These are good first observations but they can only really apply in specific circumstances. Converting core's capacity in run queue length can only drive a loaded system, not a mostly idle one. This mechanism will also cause an increase in latency for threads running on performant cores. > > There are several theoretical considerations that should be met *together*, such as fairness, latency, bias to performance or to energy (policy), affinity, cpusets (directives), etc., and... > > > Before integrating scheduler and cpucap, I need to go through sched_ule.c​ from top to bottom. After that, I'll add new functions or drop existing ones from the cpucap framework then work on the integration. > > ...there are some practical considerations too. ULE maintains per-CPU run queues and does inter-CPU thread exchange relatively infrequently (through the so-called "long-term long balancer") for fairness. It will not exchange two threads on two different cores if there are the only ones running, which again is unfair if the two cores have different performances. > > A general scheduler must cater to a variety of workloads, and it can be quite difficult to improve some characteristics without degrading others. We certainly don't want to rush things. > > I invite you to read the https://wiki.freebsd.org/Scheduler/Hybrid for a glimpse on some of the trade-offs involved and a wider perspective, which however is by no means complete and for which input from you and any other interested parties is welcome. > > Thanks and regards. > > -- > Olivier Certner Hi. Not yet read diffs and existing codes, sorry if it's already done or known not works effectively. Just an idea, if existing schedulers are already NUMA aware, adding another layer describing the attributes of cores as leaves of each NUMA domain could help. This is because (AFAIK) single NUMA domain could have different types of cores. Regards. -- Tomoaki AOKI From nobody Thu Jan 15 01:45:49 2026 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 4ds5RR48qgz6PC2q for ; Thu, 15 Jan 2026 01:45:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ds5RQ6VwSz3bs3 for ; Thu, 15 Jan 2026 01:45:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768441550; bh=zDXf6giXolMSg3NH9MGFs+e7cV35jXMRtHxpUkpg2xo=; h=Date:Subject:To:References:From:In-Reply-To:From:Subject:Reply-To; b=D5tmG/m33Zj37av/VZ0zD3d8YYVrgttPCeUzHimS8NrXhetbYsCWX1oxz+6rCcVhfWM5v2NHyjpgYHcMF8i62YYgAe4E65mWxvZ81y24M2c6ZbcdC+6u1Z6duirbkVb4Att8sSUwEaDaS26iZlv4LUQuCoV3c5o5ifM9dBPMaZkHzsgPNcI8Rg4ia1FED3Nx4ya7S/pf9WWZeAoTSdNTqvYNlioIAVUXP27TvqlziGB6ooSNbTTfCoMK+CgcaZwkTnOJjEK1+ijk7txZbFdRsi4Vncn+nt5P3wYwzQ7jFnuzhts/F7yroXa5yKufOtSbUzxuUHQv0qm7KGhg5HMSSA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768441550; bh=MFFy2vcmJmGbtck3OHhaaOefocNSpzpHRWwLGelsKy9=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=L0qzyhykP5QElNCFfOEyBZqeaGb6t/Jp8MaRSiGdyyxJb2RQ1NkrzcmHx6pyODzSbvjuZrLlvDCxTPvjhd4OBLFEEXaIt148WdvM4xLKLlY9I0qgVIzjhBx95C3ohsQpYKxw3E2iR2aJW8Mzlmpadoji/lU6nNztOuAInqSIOrCBIZXJBAZ75M3pzT8AXPMW/H0Su7/QeM9xBANDhZvZok7bEjilt/HMZ+JSUBjlY/mTHkLdD7XcYDpgGJj0qd6QX1++9no7iluuIc0UVQv/R3CRwusgtGwmZTKQPADJsUD6Znwb6IiNUEbPA+geJ23tJ+KixutrV1Q1iCfqLblRdA== X-YMail-OSG: AgIeJeUVM1kZ30ZEORbA0C4szBox6lAC0OryAQ.GuJlAcG14RrAxjDkhdcGHnIf Ld9ly3Uob0qX2WwPfzDVydc8UrJtM7xbyelN.iBijdBbyGZFncwLbNVzJTSLoc93Vr31WPMoi87o vCQXWWqyW_lCvvFz6e_DYQn_KFhkqU00fLLv9EodE_ffbp2tAL2UphVdG4fWzNtzYVj8OCJ4Uk4p emLBFTwtJILT4eZkwVEomOYdQJb2PmDp938o5IKqMrSQJneeI4SJwUxc7gpRWlqMX6DuS4fe0.y9 fuGdHyC0ynHtBfDgBn.xgvxj85ebLP5BKNBccngZSBN2DsnBMMVHqM8NAoez_oZdTVwUMjv2Fdp_ v2YBaKASe8TdyHS19IeLIg_l.d7UTg4TTz.1dU3aYvq6oHwySRDiahaMXzxyCHrsDSaQIZWMJhvT dTYUc_y0O_bSPclX67w5G7qGwK6ql_j7f545D.FXrqmv_0e09hk_rFdhdqmVCofeBLSF35Im.dgJ TcTuyT.KEtxvZGFoDtod3QfeR8.1nnjnulNNcDS2d3lojG1pqJoWvfx.YtrMsMIrIVNwDxGuOuSR rjfjMf_CmsjfSQTt1oDmkUdHX6z2fi.JgJjKELvdWIo6ZU61QD0fSVEwyT7oIbW9_o1R0yNqbnj7 LSeQPzTg40bHYohZsCvmyLW3DbqGQqbYf4.BjaxO0KPWq_v6LW7WTi7Y.4glcyZwGmigghLkRtyc SXHckenBCVHsi7kB5lTYBVnq_XJWypcuFyd0wpMWPhHGDC9bnYNNWMfGokHCyw0O1uN3yyG0af5l o9brsCjLYzy7ciJtGsmRsm6Bdj1Xt6stvaG241KrdzkG2YFcoU_rJF0oZEOrC4TsACRJT.ZZKfTL 3.sIw158QSrBwguBsA3.oDVssAqv8Y7GQesn8b2TUiNUXXsgoZLyJ5VRu.TbdCS1uAAqyxKpds3_ H5WzFzt6PjGSvBgOC4G3s1HShcuaeYf9vx1xlyK7egNKoagTVeWGFrxqxABbeY.6OHp_ChqSVPMc PP9A1oMCiltpcnk5bziej_ZEnMGDk8sCtnomSK8gcYEKFbd0WdFLggSNZG.Jzqd15qRdSdnj1VKM Oj8WlabdiCZ3929SKh3Nkrwvy5b6II_H.0dOSJppqbRHCMAdb0OO9zcNvu4N2nlp9CHHlLQvglH0 ETUnUP4DyMQHVHCRVAzexjc5VpUh2EADAHszKlIwXTtw8wfnU0RJB9jBperPO8bqp42YNemi_a.C 3OfEcAd7OE677QbF6XUGP.M7JZ6CNoHDLEXbyLXyX5lL2_iNa9xrTpV3Y5_JeypeFXGOZKNyidZM PFk85cra35UpK3wQu.MRfkFGhA6ch9.FkltrmLS7wkEk_mf29OTqh3MCPKa5_flKB3bqO754bMY5 D0cgtg9irNjU7D2dmgVnLFCxsvPK5a1bcbCVDS2NlnrICCQXb_Z69t8SUW4mS38Nkvz1w_16.qwh ouExMBGhZnmLohzBPggz4ErpFpMoKMKP2myh3L0lq0ngYknYQRFM6hdmyxVfsofUb2WnOnvtOH7N u2J8KdoE.e6XXG0GQCOPpnPT8jfvocH7cA2zMwrQbt1c0MsInEUCKKeOVcpsratg8l_JSsHJJiUR lXrAn90pg1mChcj_sAEMwo07tqMjhAQWYQpqNmsqOhaLarUH5JtUFz0f89VakFUj6o.MMBmfI1vf s2.QzsrdMvyyfLr9fmmHGm8VnJOuC5SqiMLM8lwHwRUYfowvRhc4nimMpZbgimYmIVgbrojF3mXy X6NkubZR4SKewIcC9rqrl7ZXbXoGmrdrHfD.dZPT5GMDQhmdC1pWmziD0mI3uvNgN81_Mx1qG7mp nq_qLNsWJhDr2x00EDlXj8O.Ua5Z_wNieTi6xZQl5hK3jSGlp7mJ0YL..I7xWl.wjsiCuGW02zA2 .1A0_30v5sN57HIuyPfaVTVzCA43nOVasNtCFb_mAnvcgyh.3beFT_GbVlZJhm7SqlguqKRqGUkg YU.HXbiv.B4YPOtMR4diDq3i69ByX3MTymyioiw.ou0hY_lHslX6.w5t6re_zBvHYGX7klIrE.QP rp.q8TBkivAA1ci5HEGOfRSvI2M_4P7OMeRTaBhuqhXtqL3sHSJpYGDPxbhIgGjlO82TA6BNBTQX cjC.cqaUKlWIiII9AwLEpyfWGH9NWPBJUzCTYM__e9J8LEx32tNKTizKEs5jWRaj2EzR2Wp8EETh 0J63Qjykwt.9j6lbG9y2y_7MSpd4SyA1sAX0EIfjs.G3Gw2qUjn0kV6NvSJL6ndBfaNjz9OnjMot ClCbWGb30C32coM.RUbglb2pZrA-- X-Sonic-MF: X-Sonic-ID: d591901e-5985-4870-8457-afd8f7d832a4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 15 Jan 2026 01:45:50 +0000 Received: by hermes--production-gq1-86969b76cd-fz94v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cda8c54a5eef7d96ba033ebe5d0c02fa; Thu, 15 Jan 2026 01:45:49 +0000 (UTC) Message-ID: <70c03489-a21f-4205-b73c-29015b0f2ac8@yahoo.com> Date: Wed, 14 Jan 2026 17:45:49 -0800 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 User-Agent: Mozilla Thunderbird Subject: Re: HMP scheduling on FreeBSD [An FYI about how vermaden's reply displayed and some about why] To: vermaden , freebsd-hackers References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.24987 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4ds5RQ6VwSz3bs3 On 1/14/26 14:22, vermaden wrote: > Hi, > > one may also think about adding rc.conf (5) settings like: > >     sched_fast="postgres nginx" >     sched_slow="cron at zfs-scrub" > > . . . > thread and/or review my cpucap patch at D54674. > > Minsoo >   > > I got very different displays of your message in different contexts. That appears to be because of having both of the following two types of parts --and the specific text in the "text/plain" part: --=-qYugoi0WV8X4mxSZBSyM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable . . . --=-qYugoi0WV8X4mxSZBSyM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable . . . That was the order of the two parts as well. The: --=-qYugoi0WV8X4mxSZBSyM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable part contains plain text with notations like: settings like:    sched_fast="postgres nginx"    and: "Minsoo Choo" <minsoochoo0122@proton.me> and so on still present in the plain text. It was one big paragraph with no plain text end of line formatting or such to structure the text presentation. Web browsing to: displayed and wrapped that one huge paragraph based on the window content area width. This note is written from a context that instead picked to use the part: --=-qYugoi0WV8X4mxSZBSyM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It was very normal/readable. But it would not be for a context that does not translate HTML. The two newsgroup reader interfaces that I've been experimenting with for use of news.gmane.io for FreeBSD List use handled the message differently, one using the plain text (NewsTap on an iPad) and other one using the HTML (Thunderbird on macOS). -- === Mark Millard marklmi at yahoo.com From nobody Thu Jan 15 01:58:10 2026 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 4ds5k53094z6PCc6 for ; Thu, 15 Jan 2026 01:58:37 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R12" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ds5k40H6Sz3dfX for ; Thu, 15 Jan 2026 01:58:35 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.18.1/8.17.1) with ESMTPSA id 60F1wBG1048973 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 14 Jan 2026 20:58:28 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Wed, 14 Jan 2026 20:58:10 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: HMP scheduling on FreeBSD [An FYI about how vermaden's reply displayed and some about why] To: freebsd-hackers@freebsd.org References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <70c03489-a21f-4205-b73c-29015b0f2ac8@yahoo.com> Content-Language: en-US From: George Mitchell Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== In-Reply-To: <70c03489-a21f-4205-b73c-29015b0f2ac8@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------NquTQvrjui99BtR0nPaGIDE4" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on mattapan.m5p.com X-Spamd-Bar: - X-Spamd-Result: default: False [-1.37 / 15.00]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_MEDIUM(-0.08)[-0.085]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; TAGGED_FROM(0.00)[freebsd]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[m5p.com]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~] X-Rspamd-Queue-Id: 4ds5k40H6Sz3dfX This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------NquTQvrjui99BtR0nPaGIDE4 Content-Type: multipart/mixed; boundary="------------MvW34hDdXK85liZy4ZOmxhPu"; protected-headers="v1" Message-ID: Date: Wed, 14 Jan 2026 20:58:10 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: HMP scheduling on FreeBSD [An FYI about how vermaden's reply displayed and some about why] To: freebsd-hackers@freebsd.org References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <70c03489-a21f-4205-b73c-29015b0f2ac8@yahoo.com> Content-Language: en-US From: George Mitchell Autocrypt: addr=george+freebsd@m5p.com; keydata= xjMEZaHDbxYJKwYBBAHaRw8BAQdA2W6oBfS8haXY0/Ft4zS1OTLYfC8EBIADPTgMQdh85C3N KEdlb3JnZSBNaXRjaGVsbCA8Z2VvcmdlK2ZyZWVic2RAbTVwLmNvbT7CmQQTFgoAQRYhBDpv v9n4+UzMLAJ8EZocD3futmd9BQJlocSiAhsDBQkFo5qABQsJCAcCAiICBhUKCQgLAgQWAgMB Ah4HAheAAAoJEJocD3futmd9SxwBAJUi6DNdVhWCZBTv5XGy1g0JgApLWe/3S0M0zz9sn7/L AQCcJcV5k5s2rt9J5C1AUm6XVsuneVvIWXO5j1GKWk0NC844BGWhw28SCisGAQQBl1UBBQEB B0AaFz/6B95RRvjOdLZr5fSdhuIHvwr24H3ePDZSw6wlUwMBCAfCfgQYFgoAJhYhBDpvv9n4 +UzMLAJ8EZocD3futmd9BQJlocNvAhsMBQkFo5qAAAoJEJocD3futmd9RXsBANwRD9RE56F6 /jeZOrujHICLcgPiOt50Y6866v9OUTjUAP9GlC1aopfBpNwuPLJBam7oBaGqvY98VDhzOjoT 7DNbCQ== In-Reply-To: <70c03489-a21f-4205-b73c-29015b0f2ac8@yahoo.com> --------------MvW34hDdXK85liZy4ZOmxhPu Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMS8xNC8yNiAyMDo0NSwgTWFyayBNaWxsYXJkIHdyb3RlOg0KPiBbLi4uXQ0KPiBJIGdv dCB2ZXJ5IGRpZmZlcmVudCBkaXNwbGF5cyBvZiB5b3VyIG1lc3NhZ2UgaW4gZGlmZmVyZW50 IGNvbnRleHRzLg0KPiBUaGF0IGFwcGVhcnMgdG8gYmUgYmVjYXVzZSBvZiBoYXZpbmcgYm90 aCBvZiB0aGUgZm9sbG93aW5nIHR3byB0eXBlcyBvZg0KPiBwYXJ0cyAtLWFuZCB0aGUgc3Bl Y2lmaWMgdGV4dCBpbiB0aGUgInRleHQvcGxhaW4iIHBhcnQ6DQo+IFsuLi5dDQo+IFRoZSB0 d28gbmV3c2dyb3VwIHJlYWRlciBpbnRlcmZhY2VzIHRoYXQgSSd2ZSBiZWVuIGV4cGVyaW1l bnRpbmcgd2l0aA0KPiBmb3IgdXNlIG9mIG5ld3MuZ21hbmUuaW8gZm9yIEZyZWVCU0QgTGlz dCB1c2UgaGFuZGxlZCB0aGUgbWVzc2FnZQ0KPiBkaWZmZXJlbnRseSwgb25lIHVzaW5nIHRo ZSBwbGFpbiB0ZXh0IChOZXdzVGFwIG9uIGFuIGlQYWQpIGFuZCBvdGhlciBvbmUNCj4gdXNp bmcgdGhlIEhUTUwgKFRodW5kZXJiaXJkIG9uIG1hY09TKS4NCj4gDQpJJ20gdW5mYW1pbGlh ciB3aXRoIE5ld3NUYXAsIGJ1dCBUaHVuZGVyYmlyZCAoYXQgbGVhc3Qgb24gRnJlZUJTRCkg aGFzDQphIHNldHRpbmcgb24gdGhlICJNb3JlIiBtZW51IHlvdSBnZXQgd2hlbiByZWFkaW5n IGEgbWVzc2FnZSAodXBwZXIgcmlnaHQNCmNvcm5lciBvZiB0aGUgbWVzc2FnZSBkaXNwbGF5 LCBiZWxvdyB0aGUgaGVhZGVyKSwgY2FsbGVkICJNZXNzYWdlIEJvZHkNCkFzID4iIHdpdGgg dGhlIG9wdGlvbnMgT3JpZ2luYWwgSFRNTCwgU2ltcGxlIEhUTUwsIFBsYWluIFRleHQuICBT byB5b3UNCmNhbiBjaG9vc2UgaG93IHRvIHNlZSBpdCBpbiBUaHVuZGVyYmlyZC4gIChJIHJl Y29tbWVuZCBTaW1wbGUgSFRNTC4pDQotLSBHZW9yZ2UNCg0K --------------MvW34hDdXK85liZy4ZOmxhPu-- --------------NquTQvrjui99BtR0nPaGIDE4 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQQ6b7/Z+PlMzCwCfBGaHA937rZnfQUCaWhJswUDAAAAAAAKCRCaHA937rZnfcXq AQDLqv7C8/2sWYjYNBcEGb13LGzuabghCQsCAVjH6guIAQEAmPYGJZzfJB8SkFSbWFN14wJ7HqFh xfz/JQTkCK/w/Qs= =xb1/ -----END PGP SIGNATURE----- --------------NquTQvrjui99BtR0nPaGIDE4-- From nobody Thu Jan 15 11:31:57 2026 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 4dsLRt5xpgz6NpxR for ; Thu, 15 Jan 2026 11:32:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dsLRt5RDPz3Y2N; Thu, 15 Jan 2026 11:32:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1768476730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=soHpxVymYea2J7ylmbAqxk/6woXs+PEe+r1pOho8yCQ=; b=gx79wpu4VhsMki9OBoH8zroyfA/ZFIlnYI2g1CEOCmzfwj2suWzGbxul2kPZguFRtmrIHP OLSQE/g5+04jSrL/L6Ifa1gpLbl2LfELHRZBuqNzo3G/e07AnB2ipFrzU8peyXccP++Cy1 DleAnVPaDXW2MwVEmpvK5gkUI1NXm6VfmrSEjiF1kjMo9J4AvW4iA3dAGn9/SBoT7NmzRn D+k+Ht7V/X5zbJMW/mNA7ZS+4YQV4KEfBvBA1RGC+JntJPpHyCc1tMAxby4ys6lkRBxFnV il7f1Tmm8suUIrWxg9BtTaDMn5D/Ib9nWHjUzfRMSPheWutVt4WtFgNSYGsEtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1768476730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=soHpxVymYea2J7ylmbAqxk/6woXs+PEe+r1pOho8yCQ=; b=V9RPSLzdK9ehK3MRFtPBmTVTMOnDFdsvNs91fhs0u+TIVIFG7xE6Piwjcv3hIco+FTkg2R NjHZI7C2+2kBxObVkVTS5krcnq9pTRI3KKNXLWUpkgMMHj9Ow0GoWGejRi93Buquo6MBN0 JS34xvSHiwhulSBMbVyYzZNYXd0Nz7/jeq3Yvl90U08DOcaoBhDKtrj4HYt42mAyL9/izq MPF2EZarolunDAxATXIFgTICf9gqs1d1DmHwr/ktZGybLuxNiok2LWUYV5+9sEMMOmY0oA Bmokm8J0bEjAu+sB7fsY0D1KlLikuhpzF3PpkAjxkWj7vIef/YO1Hth5qQm0BQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1768476730; a=rsa-sha256; cv=none; b=KAAeGWOuVgzkHSfqz2IbIRffpbwkkuZPcSgVeb1ux0v1qsyTf+XbIfJTFcamsQOKsnxwTA XaRNDQ1lz3YXkoL9n3d5yFldTBSQToaemwEArY7kvLiTheNcMW4JyGgp+Q8ZDUsuMrVU9U WRuV5iHP9Yli1F/8gOx2b4xGJmFrAjbfDO2MwVXZNxjLIj/P2JVWdMmfFt0eqsvRDU/HoX ZL46DRK+ExBgF4NIh0JaDsVXe/QZkVREmy141jIa9KwpD0Kt1HVD2/TzTNY9VK0txgkVq0 /VKDArZ3kVDtnh1TpvHx4kMLerpPXAR9yoR4LQvMKvvA0aZoheMs4Ys0WjMgzQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (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) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dsLRt4jhDzCKx; Thu, 15 Jan 2026 11:32:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host86-143-41-230.range86-143.btcentralplus.com [86.143.41.230]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 0A8B5113E8; Thu, 15 Jan 2026 11:32:08 +0000 (GMT) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: HMP scheduling on FreeBSD From: David Chisnall In-Reply-To: <1886427.OVFmXjEfDW@ravel> Date: Thu, 15 Jan 2026 11:31:57 +0000 Cc: Minsoo Choo , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <1886427.OVFmXjEfDW@ravel> To: Olivier Certner X-Mailer: Apple Mail (2.3864.300.41.1.7) On 14 Jan 2026, at 22:14, Olivier Certner wrote: >=20 > These are good first observations but they can only really apply in = specific circumstances. Converting core's capacity in run queue length = can only drive a loaded system, not a mostly idle one. This mechanism = will also cause an increase in latency for threads running on performant = cores. There are also some fun corner cases. For example, the first generation = big.LITTLE systems typically used Cortex A53 and A57 cores. The A57 was = *much* faster, but it had four-cycle access to the L1 cache, whereas the = A53 had single-cycle access. Workloads that fitted in L1 were faster on = the A53. So this can be a core x workload (or *phase of workload*) = metric. That said, treating it as a per-core metric is probably fine = unless you want to hook in performance counters and do dynamic = measurement. > There are several theoretical considerations that should be met = *together*, such as fairness, latency, bias to performance or to energy = (policy), affinity, cpusets (directives), etc., and... The hot-plug aspect is also important. The best energy efficiency comes = from turning the CPU off entirely. Power-aware schedulers want to have = a strategy for turning cores off in the way that minimises *total* = system power consumption. This is tricky for a few reasons: - There=E2=80=99s a tradeoff between running a workload for a long time = on a slow core or running it for a long time or on a fast core for a = long time. The heuristics that ULE collects to identify I/O-bound vs = CPU-bound workloads are a starting point, but you also likely need to = track the typical sleeping time. If a workload sleeps for long enough = that it=E2=80=99s worth turning a big core off (or into a deep low-power = state), that wants a very different scheduling policy to one that=E2=80=99= s sitting using 5% of a core most of the time. - Some systems have independent ability to shut off cores and their = caches. This has some interesting effects because snooping on another = core=E2=80=99s cache is usually faster than going out to main memory, so = sleeping a core but not its cache may improve performance of nearby = cores (by a NUMA-dependent amount). Similarly, shutting down another = core=E2=80=99s caches may reduce performance of nearby ones (note: This = usually doesn=E2=80=99t apply for fully inclusive caches, but most CPU = vendors have been moving away from those). Apple did a couple of things to support this kind of tuning. The first = was to add a slack parameter into the kqueue timeouts. This let the = scheduler coalesce wakeups. For example, if you have a clock that=E2=80=99= s running once a second to update the second tick, and you have a bunch = of other things mostly sleeping and waking up once per second then = it=E2=80=99s useful to align all of the others with the clock app=E2=80=99= s wake so that you can turn on a high-performance core, wake up, and = then sleep. This is useful even on homogeneous SMP systems and would be = a really good *first* step for this kind of work. The second was to provide explicit hints to allow threads to indicate = the kinds of cores that they want to run on. All of which is to say that I=E2=80=99m not sure that starting from ULE = is necessarily a good strategy, since it wasn=E2=80=99t designed with = any of these constraints in mind. Oh, and Apple isn=E2=80=99t perfect. Their scheduler currently has a = bunch of issues with systems that distribute work across threads, where = the overall performance depends on the throughput of the slowest one. = For longer-running threads, they=E2=80=99ll interleave P and E cores, so = you need to do fairly fine-grained work stealing to use their scheduler = efficiently. David= From nobody Thu Jan 15 19:03:16 2026 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 4dsXSY3zfQz6PKTF for ; Thu, 15 Jan 2026 19:03:25 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-106102.protonmail.ch (mail-106102.protonmail.ch [79.135.106.102]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dsXSY0w73z3tKy for ; Thu, 15 Jan 2026 19:03:25 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1768503802; x=1768763002; bh=CvLM2frZaZSIHYpPWmzzYYri2SnnmhDpznnZ2sQhYEo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=W4g0mKBG58J/Bvje1WGj3DWsm4bnxBYgSsulXI/AzymIWAoT4egEo4p/kOajVhIHa 1YNpm4ThIjRV3t2jOzewoPNfe7sgsofepi7L1TFRtOd+rJNkmvr7WOe6nAc43MTQjN wNegEoD0xle/x/1n5ZWG7J5BEEzNg074r8T+DjVets6ruCU3pVhermNY93iuVJx3cT KKgkCPNqT1SywRkbNnoWEC1Cwf/UPjC7Xy4cGM1sNAGMcPvF2YMc8cPxCGjl23QIfq 9cjKCf7uCfhl1mYg7FncEXl4qF24A2/eYVjhdQwuIS3AwB/t/RHPxtHIz0g+LJkOTN vWZrNQphN7VSQ== Date: Thu, 15 Jan 2026 19:03:16 +0000 To: Olivier Certner From: Minsoo Choo Cc: freebsd-hackers Subject: Re: HMP scheduling on FreeBSD Message-ID: <6tOKBjzm6105PhWG7uokCxT9_vl6KFcdZlDDZqLtJHLinaU79t1KirKeB0BU0PNg0iMFOQrbQoLLrfGQGw8ku2M-xpvO15tXI1WzdLAQ4m4=@proton.me> In-Reply-To: <1886427.OVFmXjEfDW@ravel> References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <1886427.OVFmXjEfDW@ravel> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 08d246c98536d5d4e9de582c9a60cbe9d30d78d2 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:79.135.106.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dsXSY0w73z3tKy On Wednesday, January 14th, 2026 at 5:15 PM, Olivier Certner wrote: >=20 > These are good first observations but they can only really apply in speci= fic circumstances. Converting core's capacity in run queue length can only = drive a loaded system, not a mostly idle one. This mechanism will also caus= e an increase in latency for threads running on performant cores. >=20 > There are several theoretical considerations that should be met together,= such as fairness, latency, bias to performance or to energy (policy), affi= nity, cpusets (directives), etc., and... >=20 IMHO, ULE doesn't do great job for fairness. There was a freebsd-hackers th= read [1] back in 2023 that criticized ULE's fairness, and I believe this is= ULE's limitation by design. Someone in the thread said the interactivity s= core is "bogus": although I wouldn't go that far, interactivity score sacri= fices fairness and we definitely need patches to handle edge cases (similar= to what CFS experienced on linux side). ULE's interactivity score mechanism also pollutes priorities provided by ni= ce value. Someone in the thread said nice isn't relevant anymore these days= , but I think it should be respected as nice value is crucial to UNIX sched= uling and many softwares still depend on it. Interactivity scores and nice = value can be messed up together pretty easily compared to CFS/EEVDF, which = can cause performance degradation that users didn't expect. It also makes h= arder to predict how the system would behave under certain circumstance whi= le many of the "interactivity" assumptions in early 2000s aren't true anymo= re (e.g. graphical applications). It would be nice to introduce fairness scheduler like CFS/EEVDF[2] in FreeB= SD, even though that might require cleaning up existing sched.h interfaces.= FreeBSD kernel has been too dependent on 4BSD/ULE since early 2000s, and i= ntroducing new scheduler will break many things. By establishing a better s= ched interface, this gives opportunities for others to implement their own = scheduler on FreeBSD. > > Before integrating scheduler and cpucap, I need to go through sched_ule= .c from top to bottom. After that, I'll add new functions or drop existing = ones from the cpucap framework then work on the integration. >=20 >=20 > ...there are some practical considerations too. ULE maintains per-CPU run= queues and does inter-CPU thread exchange relatively infrequently (through= the so-called "long-term long balancer") for fairness. It will not exchang= e two threads on two different cores if there are the only ones running, wh= ich again is unfair if the two cores have different performances. >=20 > A general scheduler must cater to a variety of workloads, and it can be q= uite difficult to improve some characteristics without degrading others. We= certainly don't want to rush things. >=20 These days I'm leaning towards fairness schedulers over multilevel feedback= queue. While fairness schedulers are general and take no assumption on wor= kloads by default, MFQ incorporates components like interactivity score to = boost performance under certain circumstances. This works well in NT and XN= U kernel where 1) the OS is built for specific usage (GUI desktop) and 2) s= oftware they are shipped with OS like desktop managers can directly interac= t with the scheduler its use cases [3]. However, operating systems like FreeBSD and Linux run under different envir= onments (server, router, GUI desktop, etc) and fairness scheduler is more s= uitable because it is "general". Although it sacrifices performance under c= ertain circumstance (e.g. XNU scheduler handles Aqua better than EEVDF does= for Wayland/Xorg), I believe on Unix world window manager developers shoul= d handle this through nice not by asking OS to expose scheduling APIs like = XNU does. > I invite you to read the https://wiki.freebsd.org/Scheduler/Hybrid for a = glimpse on some of the trade-offs involved and a wider perspective, which h= owever is by no means complete and for which input from you and any other i= nterested parties is welcome. >=20 > Thanks and regards. >=20 > -- > Olivier Certner [1] https://lists.freebsd.org/archives/freebsd-hackers/2023-March/001938.ht= ml [2] https://citeseerx.ist.psu.edu/document?repid=3Drep1&type=3Dpdf&doi=3D80= 5acf7726282721504c8f00575d91ebfd750564 [3] https://developer.apple.com/library/archive/documentation/Darwin/Concep= tual/KernelProgramming/scheduler/scheduler.html From nobody Thu Jan 15 19:21:20 2026 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 4dsXsP6GDDz6PL9L for ; Thu, 15 Jan 2026 19:21:29 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dsXsN48j6z3vp5 for ; Thu, 15 Jan 2026 19:21:28 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=AadBepIl; dmarc=pass (policy=none) header.from=hardenedbsd.org; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::22c as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org Received: by mail-oi1-x22c.google.com with SMTP id 5614622812f47-45c798c92edso752660b6e.1 for ; Thu, 15 Jan 2026 11:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1768504882; x=1769109682; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7VCK+L+9EzJrr63/hrUlRSiPfQ+GRY+lRvnTV2XIFoU=; b=AadBepIlVBIOMgAWOCvTSfs1ZSkrVm5vj+4QzoED0aOTv7yZtIVtn9EnNiOlPkA0M3 eUzQOcabJyH2EBvapaXVXrNC2fnylAZ22brWVIJTuuo+nKJ5Q5WPc63/T2JkA1Kk+C9A +GMpo4KjvLa0h1qiGmOdQjZ2XYKjwfPo2oyXGtPt8iL01x6q2fDdfJTG6ddZF8ZcFdWE AOrUMjGLtCeuLeqrOBw1s7Ai1co3u2fe+v0L4eSrIJc1mueWWOfrcihOfz+xR/Z/mV5a Lm2L6SaWowj1JWjMGYDuNWy1+HGvPK3AhyS3R7BaC0f3oLXmRGSTVX7TXyE4eFb74DOf EdUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768504882; x=1769109682; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7VCK+L+9EzJrr63/hrUlRSiPfQ+GRY+lRvnTV2XIFoU=; b=CUWNt4rtcL+F59sWoljKRBZzvHFmMK4QlfKZoVnlF7+xzw4f6zdy5hBBM8fdnUes7K DkUTViOda9RfB52Wyt9KKKHAE1NTV31weEUvImFbbSHaWH9wAC8lz3WfIZxo5qFUf2jk gp5h4HbOoqqCE+5iq3G+T6NlU9uv/zBV3iDPns3mU0tf5OTpA8Fg0dF+g3MXfjkSlFaB Dq/HxRnLAUFnwsJ6oUuvG0Wk82YR1/FBWFu9Fjpczd8apwnyGmMdpjzo4j5nXr82G+2w V4Au3Hyy2fPmdYailbkBtrz+9HQHzvOq+B/aCHCuPPwTL5U1NPFWox3kTFDVTKX3Gi2c 44IQ== X-Gm-Message-State: AOJu0Ywf17VK4Tl6JM5nyTUh8xKzqLUzzDXcOow55KpJ3JMbySvCAgbx y6X1dXmB+AhiEqdwlRZGXq/y6C61kfGFtwJ/la6HNUlSkihEfx7iopSQyTSWBM5Uog/eRmToiSm ou+On+v0= X-Gm-Gg: AY/fxX5ie1AsGGigeLHi1aRtegP4iwMH6n5XkwbFVd32p0ZxHKF+VT1XEGw9qnXiM5d 5hwRLPc69ornqT4EHF8GsI6MzjIivQ082yTR7qt2WU09a/JJXzloGb9C5yM5S6TS9v4jrlla2k3 bZNQyuLgizLiO4dNs1gdY8ANJF4peld7siWxLQrmk4o9ItBMnoGkulBoYn2IqgRMwzp6KZQrORi OYUs3f3EUNONTe5PWgP/anySsdNLA/AZru410ygGQLurtlgWTZCxlIb8TucOypLCKXqlS6V1hHf GSHyZDsQ6irzvbSS8C+5d04GJBhSU/TV3MAAD57iDohgyyHV/sxmp+KfteJXluwWSZOrCmFCxP+ OkB0VBwK2p3mIZqA81UqBl6l/lmSbq0aDENviFugWsr0oBhsBGFW5kVIqnwD05ko/L0CU X-Received: by 2002:a05:6808:191c:b0:455:7ccd:d11 with SMTP id 5614622812f47-45c9bf77e61mr277735b6e.24.1768504882142; Thu, 15 Jan 2026 11:21:22 -0800 (PST) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 5614622812f47-45c9e08df1bsm78905b6e.22.2026.01.15.11.21.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 11:21:21 -0800 (PST) Date: Thu, 15 Jan 2026 19:21:20 +0000 From: Shawn Webb To: Minsoo Choo Cc: freebsd-hackers Subject: Re: HMP scheduling on FreeBSD Message-ID: <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n> X-Operating-System: FreeBSD mutt-hbsd 14.3-STABLE-HBSD FreeBSD 14.3-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> 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 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qjjjsycu6227j47j" Content-Disposition: inline In-Reply-To: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.60 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[hardenedbsd.org,none]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; TO_DN_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22c:from]; DKIM_TRACE(0.00)[hardenedbsd.org:+] X-Rspamd-Queue-Id: 4dsXsN48j6z3vp5 --qjjjsycu6227j47j Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: HMP scheduling on FreeBSD MIME-Version: 1.0 On Wed, Jan 14, 2026 at 04:10:15PM +0000, Minsoo Choo wrote: > Greetings, >=20 > For the last few days, I've been working on scheduler optimization for he= terogeneous cores ("HMP scheduling" from now on) on FreeBSD. After days of = reading specs, planning structure, and writing code, I came to a model that= can be utilized for implementing HMP scheduling. I opened a first revision= on Phabricator (D54674) a few days ago but decided to introduce this model= in the mailing list and hear others' opinions. >=20 > First of all, HMP-related code (scheduling, provider, cpucap framework, e= tc) are only built and enabled when "options HMP" is specified in kernel co= nfiguration. Of course, this shouldn't be activated by default because it's= in experiment status. "options HMP" should be added to kernel configuratio= n to enable this featured and this won't be enabled by default until the ma= jority of developers believe that HMP scheduling is stabilized. >=20 > The first component of HMP scheduling is "cpucap". One issue with HMP sch= eduling is that identifying the capacity and scores of a processor (i.e. pr= oviders) is machine-dependent while the scheduler code should be machine-in= dependent, so cpucap acts as an interface between the scheduler and provide= rs. CPU capacity and scores are stored in pcpu structure while the machine'= s cpucap status (e.g. initialized, has dynamic scores, etc) is stored in gl= obal cpucap structure of type "cpucap_t". It also includes functions for sc= heduler and providers, such as accessors, setters, finding "best" cpu, etc.= The review (D54674) adds these facilities under HMP option. >=20 > What are capacity and scores? Capacity describes cpu's heterogeneity (mor= e information in sys/contrib/device-tree/Bindings/cpu/cpu-capacity.txt). Th= is is static; it is initialized on boot time (e.g. from device tree) and st= ored in pc_cap_capacity in pcpu after being normalized to 0-1024. If it is = not provided, the default value of 1024 will be used. It is static and core= specific; if a performance core has capacity of 1024 and a efficiency core= has capacity of 600, this means all performance cores have 1024 and all ef= ficiency cores have 600, and whether they are throttled or not, this inform= ation stays the same. For this nature, capacity is hint for loading balanci= ng. By dividing a core's capacity by total capacity, we can assign an equal= fraction of tasks to the core's run queue. These cpucap information, inclu= ding enablement status, has dynamic score, individual capacity and scores, = can be queried using sysctl. >=20 > On the other hand, scores reflect the real time status of a processor and= are normalized to 0-1024. Providers like Intel Thread Director give the cu= rrent status of each core and feed it to pc_cap_scores in pcpu. Scores are = used for thread selection. For example, if a performance core is experienci= ng throttling, its score could go down to 1000. In that case, the scheduler= will prefer core that has the highest score. Scores are completely optiona= l because many processors do not provide this, and when score information i= s absent, cpucap fall backs to capacity. Since scores are dynamic, they are= retrieved and set using atomic operations. >=20 > Providers feed capacity or score information to cpucap. Capacity provider= s such as device trees and ACPI CPPC run on boot time and feed capacity inf= ormation. If there is no capacity provider, (again) the default value is us= ed. Score providers such as Intel ITD are implemented as device drivers. We= had ITD implementation patch (D44453-D44459) back in May 2024 called cored= irector, but it was neglected. With some modification, this can be the firs= t cpucap provider. Providers cannot be loaded or unloaded on runtime. An ex= ception is Arm SCMI which doesn't feed information to cpucap, but instead, = the scheduler should control and request CPU's performance. >=20 > Before integrating scheduler and cpucap, I need to go through sched_ule.c= =E2=80=8B from top to bottom. After that, I'll add new functions or drop ex= isting ones from the cpucap framework then work on the integration. >=20 > If anyone is interested in this implementation, please reply to this thre= ad and/or review my cpucap patch at D54674. Hey Minsoo, Thank you very much for working on this! I've merged the patch locally on one of my systems running HardenedBSD. I can confirm compilation succeeds (and boots). I'll be paying attention to this thread for updates. I'm happy to test future patch revisions, too, so please reach out even if you want me to test a one-line change. I subscribed to patch D54674, so I should see updates there. One question I have regarding the security posture of heterogeneous cores is whether constant-time cryptographic/string/math/etc operations take between cores. Would it be possible for an attacker to do by virtue of the different types of cores? For example, when installing FreeBSD with a geli-backed root filesystem, geli determines how quickly cryptographic operations take and will adjust the number of rounds accordingly. If that operation takes place on an efficiency core, would that result in fewer encryption rounds with geli? Can some sort of timing oracle exist by virtue of the different cores? How are speculative execution vulnerabilities manifest? I'm not expecting an answer to any of these questions. I'm just writing down some thoughts. But, if anyone can answer those questions, all the better. :-) Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --qjjjsycu6227j47j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmlpPikACgkQ/y5nonf4 4fr9LA/7BMsMp5yNsxx4PrdFvIjVpR+3ktslPwIOvPYpib/c1iAO92e/b4LtDC2O AjAKCJDk8cTj1U3tPUSZJRa661iObTj18d9JQ3SUhLBUQ9pOIjVRrV2YHbDLgi8p 1kxMpSQ4NaDjfi97rky6CeSYc1FcMd2pO57O0YsioXMU2A7Gg922QNPysqWYXJFz OCXzEZwUTuCeiTNuN33D/D00fq/yE1io+lgrNDCZs7CyJ43um03WJgEkLek45oaO OtZhPrR5Ecr5leCGLLAusMM8Uc5bYyTANw+u+H392SlTUZcCQ0Rzi+VYMRtsUNiH HK2qVyCYSLGo9SpC3RHhESShDtFytMVlqm6HfReOINDhm2Hb3rQyjbu26l3xvrjC M5lSbboUrciPafUetBXmWkveP5ObOUlHRdXW+FvqdzQdgVJneRXP0oVVD54KxK0B aIGCFAz58pD5y8zTx+REPQUw9TFu3dAP+kDdpP/kHBDUVtC7kIpis3a+STiioHzi aVNjVuQMAZpucIRxfDMCEPLubKogpLok6iwbXoyuM6asjwsbOhs87nSTfHJ4lt7Q ArqyvtaSkpSGfexKLW88sb3lJb7BJG+Ekr47P4FjfI1SuHRqFcwiRCfrVSR6fp1k I8XzlN+1w7+HAQ2+9jo83xyUkQsg3JqrJ3KXYkJwctfD6FaTuAA= =L5hP -----END PGP SIGNATURE----- --qjjjsycu6227j47j-- From nobody Thu Jan 15 20:53:08 2026 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 4dsZvF4LRqz6PR0B for ; Thu, 15 Jan 2026 20:53:13 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-106104.protonmail.ch (mail-106104.protonmail.ch [79.135.106.104]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dsZvF1zzKz3DfQ for ; Thu, 15 Jan 2026 20:53:13 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1768510389; x=1768769589; bh=1IbTfTUtgDI+e7Sd4kA2PWaFajz2wJ6VYHmlsYjNPOo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=LiQF5L8HjT1CaplMUiJoEIJH/hWYWA43bDeGkpEhm3mhaPNv+n0Y1kQSOXQYKcjl0 No9827obB2y3Wv2oyyfTUEft+eqgtgcTclnG9Diks3l+URiA7wIkaUs70hdlH1XVKM 0prVfLdAv8p+Ht9M1LjE4VIzHVArsY3eMVAUPL0ACN+2xFk86aKt36a715meKNbx+0 8YfmNpf7NvD33vBEJRbve27Q6MXe4tyOPf/2jkSaxuc45Kge2Av0O3dCAZvn1chhB+ QvjPZmYHp1+6AxdeF9ju0XT5RyX65XDn1OgVpzxfLxkL4XS1Lv/CE76+oasJX61t5d TdD1nmg4M7ncQ== Date: Thu, 15 Jan 2026 20:53:08 +0000 To: Shawn Webb From: Minsoo Choo Cc: freebsd-hackers Subject: Re: HMP scheduling on FreeBSD Message-ID: In-Reply-To: <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n> References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 41cc90c1f924e5acd0d46be669d93d14d21818b6 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:79.135.106.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dsZvF1zzKz3DfQ On Thursday, January 15th, 2026 at 2:22 PM, Shawn Webb wrote: Hi Shawn, >=20 > Thank you very much for working on this! I've merged the patch locally > on one of my systems running HardenedBSD. I can confirm compilation > succeeds (and boots). >=20 Great to hear. Since the cpucap patch doesn't do anything functional on run= time, it shouldn't have any impact on the system. >=20 > One question I have regarding the security posture of heterogeneous > cores is whether constant-time cryptographic/string/math/etc > operations take between cores. Would it be possible for an attacker to > do by virtue of the different types of cores? >=20 ISA on different cores for a same chip is identical. For example, an Arm he= terogeneous chip should provide same Arm ISA version (e.g. v9.3) rather tha= n different ISA for different cores. The scheduler has no idea on the ISA v= ersion of a specific binary. However, as David noted, different cores can execute same ISA differently. = An example given by David was cpu cycle that takes to access L1 cache, but = this can apply for cryptographic instructions as well. >=20 > For example, when installing FreeBSD with a geli-backed root > filesystem, geli determines how quickly cryptographic operations take > and will adjust the number of rounds accordingly. If that operation > takes place on an efficiency core, would that result in fewer > encryption rounds with geli? >=20 > Can some sort of timing oracle exist by virtue of the different cores? > How are speculative execution vulnerabilities manifest? >=20 First of all, knowing the performance difference between cores in absolute = scale is impossible because my proposed change (and Linux kernel) normalize= s capacity to 0-1024. A relative performance difference, which is normalized to 0-1024 from diffe= rent sources (e.g. device tree have cpu-capacity that is measured in DMIPS/= MHz) can be accessed through sysctl (still being worked on). This sysctl wi= ll expose CPU's capacity (static) and dynamic scores (dynamic by cpu thrott= ling, temperature, etc). I will set CTLFLAG_CAPRD for these sysctls so we c= an add a layer of protection for these information. The measurement (or benchmark) done by GELI on boot is inaccurate on hetero= geneous platforms. This is not about pre versus post HMT scheduler support,= but if FreeBSD runs on existing devices like Intel Alder lake, GELI encryp= tion and decryption are already done on cores with different performance. I= n other words, the best method for disc encryption is to have something lik= e Apple's T2 or Secure Enclave. Exploiting the scheduler to run a task (like disc encryption) on a specific= core is hard. Attackers can spawn many tasks concurrently and run benchmar= ks to identify the core's performance, but this information is very unrelia= ble because the task could be moved to other core by load balancer or its i= nteractivity score (however, note that ULE scheduler is by design very hars= h on moving tasks between different cores). To speculative execution, they = need to retrieve relative performance scale on all cores (thus retrieving r= elative length of each run queue) and "guess" a task's interactivity score = which is very hard and almost impossible, and make there task run in a cert= ain way by faking scheduler to put the job into performance or efficient co= re. But because a process has no idea on what other processes are doing, gu= essing interactivity score will be very hard. Side note: ULE scheduler is vulnerable to starvation compared to fairness s= chedulers like CFS/EEVDF so theoretically a malicious process can intention= ally trigger starvation under certain circumstance. However, I haven't hear= d any use cases of this method. > I'm not expecting an answer to any of these questions. I'm just > writing down some thoughts. But, if anyone can answer those questions, > all the better. :-) >=20 > Thanks, >=20 > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD >=20 > Signal Username: shawn_webb.74 > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From nobody Fri Jan 16 01:00:10 2026 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 4dshNS4x6nz6NSNn for ; Fri, 16 Jan 2026 01:00:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dshNR58Y1z3hQm for ; Fri, 16 Jan 2026 01:00:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of adrian.chadd@gmail.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=adrian.chadd@gmail.com; arc=pass ("google.com:s=arc-20240605:i=1") Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-5014e8a42aeso15300161cf.2 for ; Thu, 15 Jan 2026 17:00:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768525222; cv=none; d=google.com; s=arc-20240605; b=B1GRGbF6jaUdojYtc51ySOakQJvTbUQkVIiIeGV1chmkrHzzotlvrKVO3ApqMY0aTo a/FUmY+FuF4IKoLkVZ/nQpZ2Vl0kiy//t90U1xQbD3IlL7Y0Z7Q5kwtTmYgJcz8GuXNm Gfmr6GHkEe8mjebindw/orce+JcLlD5OnKf4KC3njZM/qRuQwMVtQPr7dQ6nqqe5lKcW N1USatCJ1F78WQtxaWpWSDfn7+fmQ4Lay/FKRZQiu7KPZWwMJii49Map+qwp2TQGm048 nr/hKQcCNJLhARbIZu1OHy2C+DJjAoy7bfFUBUIlXkbXV90aWzCMR1THMgbnL7fVFvnx Y0nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=Fr0+1E4JhxvxXzKVXJ+QyhvxQ9dnUMXuf2Iuj2slWCc=; fh=XOTiY3RZv4ng3JlF1dJJTCGNuBBJt5d+j4Uy8LptTk8=; b=XW5VzW82hCGdcP22Q3fGpwNwqRx2Oei79aaqp+9Ho1Ocb3vE7jydMayHCvIbTqynWs 8fjGS2wHvaZK/GzgcMVwkBLNxZjEC8/xnqP8kMkwlsgVf076r3QwoWqSv6AiXZkP9S/f 0QYzDLl+bv/KmtP86UBc1OU4X8S+AD9uDze43MYpnQWCRs9RRFCz0Xvx0oZBhhekJvyT AJM7mvqMmy2npERPqRavJqUpE9bHzGLSYh7RsMJskLmaf3kDBXKdr9cmrTPzX8iPRcCy +mqGFVXAnz1PqylPznij+BOOH2bdzOaos2lm8FtEMR6XbJeyaVGWxTCr9ha2eiUCRt4H GPmQ==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768525222; x=1769130022; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Fr0+1E4JhxvxXzKVXJ+QyhvxQ9dnUMXuf2Iuj2slWCc=; b=e+hLqNBpO27R0kpDiwgCfrnxsX0awFk9VWA9wNoygUZ1yAOQrzO2FsXQ3RJKIbRJ7k EB7ulXZc1bBM2wBQNk2ljV+6OD57wvFxgvDXHrc3pKeBc3BIHK9MI9Linucyg0dALoxn F9d1qFB/D5LLzT1bI4trbOkrlZ+BzwDJvK2jnAuSIeU4t+ec5Ye2ICz3PcGY+KeXLONB qTF0JJ/DL4cmOHPxQAvnWOfAS5V5ItLB7SQWVj7WpYzEQ+bQWnLQLd7ANG5b/+6Zi0O+ eUGQWy0us5ty5t8D7Dr69Z8sKAL9YTt9Wmv5xH71g3/qy8Jb/tCTeYDDtJSWXMt7nMEk tqIA== X-Gm-Message-State: AOJu0YyYxlbk8+8aiF+16ITWGZVki4EQ8cD4ZQ8nHtn7VoQkTTNxWKu6 qYTLMroriCpjPu55766BUdASZ3i81CizPCTMwpi37dKMKc5XmtP6j/Gwc/rco3uNY0u5G5PRVUU SEMYWxxMiQxAac3fuiNTu3avUcPYs6nXoxA== X-Gm-Gg: AY/fxX6gT+NJQuLXnRG9W3vL5GMMi5jxJRjfIZlTMvVkbTuqi5qazh+TzIQrJX4swqX PU7pBRM98DQ/SqwwD6iwolsjYJlNE1F6TDFJI3oN1ssmx/VLfDkctVNSo6aAb4rz2eGcyOSqhfo ijCh98bJXxUB+Xigt3MP5YcP6o+hM/04CHIABCyiHt1eO9n8Z+GFMDc5mRux3kzDDUkRF4YptOI juGXr+t/JXlbxTa9kTAw92tNGwr/Sf2vupSd5pIvO9zhvjkNNVL3b650NTXnpIhiSXztBMxlyrC hxcx7GpLFv0FpSKccO4BBQyV6VUXxA== X-Received: by 2002:a05:622a:19a0:b0:502:9da8:818d with SMTP id d75a77b69052e-502a17b0010mr19620241cf.82.1768525222427; Thu, 15 Jan 2026 17:00:22 -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: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> In-Reply-To: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> From: Adrian Chadd Date: Thu, 15 Jan 2026 17:00:10 -0800 X-Gm-Features: AZwV_QiWZwni_DeUpPXOZB8cTjJBOAwlkl5uwHQ7uQpKX5tM4NjOCp2Vil1V11Y Message-ID: Subject: Re: HMP scheduling on FreeBSD To: Minsoo Choo Cc: freebsd-hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: / X-Spamd-Result: default: False [0.07 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20240605:i=1]; NEURAL_SPAM_LONG(0.92)[0.922]; NEURAL_SPAM_MEDIUM(0.74)[0.736]; NEURAL_HAM_SHORT(-0.59)[-0.586]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.160.181:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; R_DKIM_NA(0.00)[] X-Rspamd-Queue-Id: 4dshNR58Y1z3hQm On Wed, 14 Jan 2026 at 08:10, Minsoo Choo wrote: > > Greetings, > > For the last few days, I've been working on scheduler optimization for he= terogeneous cores ("HMP scheduling" from now on) on FreeBSD. After days of = reading specs, planning structure, and writing code, I came to a model that= can be utilized for implementing HMP scheduling. I opened a first revision= on Phabricator (D54674) a few days ago but decided to introduce this model= in the mailing list and hear others' opinions. > [snip] yay! thanks for working on this! I've given you some feedback in the review already and thanks for working on that. On the practical side, there's a bunch of infrastructure pieces that we're missing that I also think would be good to get into the tree. I started describing them in oliver's hybrid scheduling wiki page that he mentioned below, but I figure it'll be good to go into here. Notably, we don't store the per CPU information about the core type/description in PCPU anywhere. eg, when we assemble the description string of a given CPU core, we actually duplicate the information from CPU core 0. On an ARM hybrid system we'll print out each core type during boot but only the first core string gets used and is available when you want all of them. On the intel side, there's a diff in this email somewhere where the Intel specific core type is exposed. We have a PCPU value in the amd64 pcpu arch area, but it's only enumerated and used for a workaround. It's not exposed anywhere generic so decisions can be made. Since it's in the arch specific area, there's not a neat way to expose the "groupings" in a way that lets userland (and scheduler, but you're looking at that) make decisions. Eg, if I knew which CPUs were in each class and had information about the class (eg "this class is superscalar, this class has more cache, this class is low power") I could assign services to different CPU sets and then later on have some policies that let us tweak things based on current system load and environment. (This btw is the kind of stuff we have to do at work on our wearable products to get consistent performance and low battery usage. There's only so much the scheduler can do before you have to think about policy, and policy requires available information.. :-) So, I'd like your ideas on how we can start populating more of the generic and architecture-specific per CPU information into the PCPU areas and expose it to userland. Thanks! -adrian From nobody Fri Jan 16 01:11:55 2026 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 4dshdx1XWhz6NT6V for ; Fri, 16 Jan 2026 01:12:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dshdw25Rhz3l1l for ; Fri, 16 Jan 2026 01:12:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768525920; bh=bTgif1hex5aPktwxNRUFaVFdtfi8s7xuuLIS9tYaz+Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=eo2sTjj9qxN6puzNv0kqolm7/hNR8GDI5EaldgPiF2E4KXccs1wreORQIsa9+Lzn/0v1ri5m4EcRNpwu5K+qRCFquC08tdVMXRUP9O3pj3jglhLjFCvj+08TagqX2HvHqSHj8jsWitgaxVlInpCJF4frP+agLBuy2Y7gao8jAjSPtUK2wCJF+ysDXttAxGOeO/4VtChdxFf/7M7P+2etcpQJW0OAgkYzXUvqZwbwcG7F4qZPz/NlZ90tNmQXlEp0fFk6RQjpKQeQ0QhDdJYxunEtjnVp+66R5C8IltaRqyVgumPslbK3Gz1X8ACS6FpWhTkeeKB7kw9ntALazR2z5w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768525920; bh=H1CPrXTvwtASJZnaiElz2cc7st0eOqpeSROT75eLAG9=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=K5C4n/k740lmr2f2LhRGiPlRTEtB7QqM3vvEIJlZ1b9Nw2yTpsZftxApZPS5BvSEnyVy7h2TJFFaYwQMDKkT1pSptqvftPtomY7ioJDhzOGGPtFMR2JHJGt2f1U/Ir3SYEVsNmVG8N9aqlgQFstoxLXhVZpBhfk51NHdCPCkoHlKvyeABaPHEesflbeOlbeoyDFjBCZ9Om7a0w+jFEbsw2YYJNbGKUPEfx8fR5H7NdJElJ+owVz/RaMXUHLaGJl2WtAth/oqOS6NImVdQ4fRG0SsSDX2WnNm6SNnF3M4EaKdYHZVnnnxTS+Ift0kvcXV6bWpy8XcdH9cHSJuoTgvCA== X-YMail-OSG: IHlSppgVM1l1lwEDeqAvD0JzpsFU6Z4uV7RtKeYkSHeogIYBkncHNPN5uh3lPQq mC.rWWT11Nj0mAfmREcgi2TguWy9qQeSatZeT8uAgD9fYkrAAmpYLojgsEN2qC25go9UqMP763.Q ceEuebUd6i1Xfq7czzjXKMkvsBwogR.1t0xa0FgqTEHp5Dw5JA50868A4D7fC9pE2XNeNtp4rR6H 6JIK4nt1qEOBY2xsO8HtrUaprx4abrs3onP6zI556kBF_NpA7rPtIpnSKg6E4SrI2ZruHj6ghGx8 nXVNMJPBZTD3Ia44iIlRwJQ2_v5vo_k5k5TolV4vxal1Qm9d5jlWKLnXxLYmxCKkIX6yyfPMPfVZ gyvo5KP2b1not37XQl5FaXRPtrEGOoXNVMVZZ2CTfKMZBL_ogBL7XH.1Af06D6rDSRlNQsL2gAwh RWYY0WlJVwXrp7v90c2l8.HLAvaqdQQ2O00tbsiJtSCJ_O.Qb8K7sZJ4kVKFJZ0RKKd4DVVAsmOI 1FF_K.DkDCmg4hbguuevKFwxLMDDqSBuBpJ8X_tMr_ykJsRcYPiDtSDfX.S3glMn2gJe0ftNGpfp WHHeS0ls9LEv_DoK_LNbYWxcousfyZ78Absy3bdjwOjeKT.qeJDkpjaMggrmx5.aDuu23hvtJ8Bh 4WzwAdWbdDqWJz1zNKFEJvJr5W3HOGO7Hab6WRLTd3j0a92RsFhVhnJzwwih0nIHvQqWWcal5f_E 8R1EpPBTrJ4PL7cKOYvDhNlVLBvIzhlBmkcpZaTRN18dHZfkFm0Rg1ptR_9a9lzlA9uP1ooZEWOx OCsMgCNpkaHs.XikVhSsZeMWJdWvCF8guTrie.igsjmf3_sGRyDAgVotzFo9vVFTalIVRScssMM1 50.9eW9.wG22XiMYKSVc91AlSZKCTrEHi5R7PgKnHEd82FpWXJ43jq6jfwZlhrbEEE_rSxhmZ8hX tsnZLBHyGyhanmzhc1WDo7iu2QpsrjjAIsnioubGAJj3NyC8D0AQr.6DmNUfpZ7hzqRUs9X951Yj k44JRUu8hAgdvy50tN5IanCAiGDkaUndaG0FKpafo2NEicqHn6Kf2cg5LOa62dzyCESvsiAWDbM7 ppu0B1DD0CgwHX91Y8UCpyaGDlLHZU6kPb9pzQYEMIKzxmqNICJTj6uQxtzu9P3frQ9QLVsb.XR7 JvnK55s4QadmaAjK45Gb3.KDj3GWwMe0JTDAhnentAWqI5opZxBNowOtcTpFITvvFGOHlBm_9T1T xFJ7V6kOuRxEzXJPd.0fGLLEycnuyNVwJWJD6QdLZ1iKsHrdsUbfaPeVWLPH3aYU1eTB6Qg7UhU3 c5G24yTYOj2yl2dHYxUx5W_d1r0.219_yu2BoLd3B1EGweXg8I927Uyz3Wy5PfexmoFxHBOoSyNF 8CccblJyGVmtm_gMIV9fuP3SzWSJ8ej5BRgSnVsJ2ZCGSvcRbDP8P7xadGOEnRzrE6usG474Wbqe gBORvtiarmAyKBQMLSrtOP1pORhaBI0a_f40qhMy52dvmUxIXRWKsbMFXV1putdgLnTdy0q4HFuF RUg9EaiLUScMkxZ7QqsTXGJSiUS0cjG617vG22RnMfFc1PqYJ9qEDkVVlnNZvX8wGLKAjnjIVneN Qomhp2wkmtxGah4Spcc3kqr0CVJIL6a8kqnRZDwsXwvS5etyFaAQSYQTvt_beP2lbmvuwxbloubB Z4_mII5mmHhMGMyrojqNjQnyUtQcSe6MCHD5TPj92SRRp5_T05Lm.w0dO1Hvd79wNwfMu9x34H8D 6Wwo1.rcG97EyLoVrRP7yPUYLVOsuWEYoNZ5h0gWT6s.WweUh7OMEThD1Qyad3Hw.t7qq0Epq6Jh PwtR249ihXffWQhgAVhyChR4CWGnMRNEUZrNzfFNqbvQEm1fZ4qbULL1pMrgTpiMXs.6RzMr1M2J dwHO.U.Uyg3fn2mpgN.KxnXeORJuetSsuJTBjAA1rYqD_TI_B.KXPKSiAa7FMRlIyXjnj.LmMWry dG9.MJfn_RsR.njmlchUuptl3Hw7MEC1oLoEpCaFpjuX3OdbqoXCW2G_UfsDnFBk7cyJtbbMQm_B 1cS.DGkg8GRseW9DIXfML3TwtTjzfcIky96ScE721vNQ4wJ.IE4YJlRqGbDwhMVPfFZNaMV2jpU9 9BFJbPGAJ1ImM7YFbIdYIGh5NQUPipcWWlnPR2Ry6tgmfvOB7lUMsdD0y2wv8JEtXcbo6ioDILLg ou6x4qqF5LO6bql9FeROCJUrxOq.q5UWww2eUoMh_sv7n3gOT3hPHFNtOBitXn7yKZ0YeR6uh2s0 8AG5TiGtlSN9BdYIxlRlbhlmI_Ad4UPlAKwKjYW_.EXVOZor2 X-Sonic-MF: X-Sonic-ID: ed3015fe-11bb-4630-b720-1974aa79cffe Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 16 Jan 2026 01:12:00 +0000 Received: by hermes--production-gq1-86969b76cd-dfbg4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5f944eeb6255d7e9d23ad1819d0a7d38; Fri, 16 Jan 2026 01:11:55 +0000 (UTC) Message-ID: <46336160-6437-4c3b-8f6e-afef62f7bf83@yahoo.com> Date: Thu, 15 Jan 2026 17:11:55 -0800 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 User-Agent: Mozilla Thunderbird Subject: Re: HMP scheduling on FreeBSD To: Minsoo Choo , Shawn Webb Cc: freebsd-hackers References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.24987 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dshdw25Rhz3l1l On 1/15/26 12:53, Minsoo Choo wrote: > On Thursday, January 15th, 2026 at 2:22 PM, Shawn Webb wrote: > > Hi Shawn, > . . . > >> >> One question I have regarding the security posture of heterogeneous >> cores is whether constant-time cryptographic/string/math/etc >> operations take between cores. Would it be possible for an attacker to >> do by virtue of the different types of cores? >> > > ISA on different cores for a same chip is identical. For example, an Arm heterogeneous chip should provide same Arm ISA version (e.g. v9.3) rather than different ISA for different cores. The scheduler has no idea on the ISA version of a specific binary. Hmm: https://www.nxp.com/docs/en/data-sheet/IMX7DCEC.pdf looks to be a counter example, mixing a pair of Cortex-A7 CPUs and a Cortex-M4 in the same SOC (my guess for "chip") --with separate connections to the AXI and AHB Switch Fabric, sharing External Memory and Internal Memory and everything else on that fabric. The statement may be more of an indication of the bounds of the intended support? Or of sub-setting which cores are involved for the FreeBSD kernel? (Such also may not be as common for 64-bit contexts.) Even with the same ISA, properties like cache line sizes can differ, based on some example of such that I read about some time ago. (Not that I could find the reference now.) Again: a point may be to avoid support for such that ends up being "too odd" for the complexity to support it vs. the normal range of uses for FreeBSD. > . . . >> >> -- >> Shawn Webb >> Cofounder / Security Engineer >> HardenedBSD >> >> Signal Username: shawn_webb.74 >> Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 >> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > -- === Mark Millard marklmi at yahoo.com From nobody Fri Jan 16 02:05:29 2026 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 4dsjqj28XQz6NX3D for ; Fri, 16 Jan 2026 02:05:37 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Received: from mail-24431.protonmail.ch (mail-24431.protonmail.ch [109.224.244.31]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dsjqh6hPlz3pTb for ; Fri, 16 Jan 2026 02:05:36 +0000 (UTC) (envelope-from minsoochoo0122@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1768529132; x=1768788332; bh=wtGLJR4NVtw164jtZErhfJjTO2zTAXu3SujF4eMYnb0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=KatWvNOkboyBqwjNE5mbr7AvyI3JrzSqypmx04MJy9BF8XUn/V8r6JZl2+GCf/QGN fUeLn/1Ubp/6XaSSchFRVnvtY7HJQCy6IZnNhUy9Ap4fbXS98EaN+HgMf3mz21GD6Y faI+4PLW8FpnEHuCKRQhECliH6c3bt2Af4vsgv8XUZcy+yjIhw513GKDNQq+NKJiOe IU9aKAQBugq2M0/Fuf9JEkNrsuUsjjH7He4l3IhN30VjqukS/ijqH8TZEX0FB1TjTZ qVi13bgR5UTKWZRBiyYm0jdLE7EqY9iy/UIqAPlifuPmV/HpyksD2MdvQiJJE8d+vn kTJmjlv6zTVYw== Date: Fri, 16 Jan 2026 02:05:29 +0000 To: Mark Millard From: Minsoo Choo Cc: Shawn Webb , freebsd-hackers Subject: Re: HMP scheduling on FreeBSD Message-ID: In-Reply-To: <46336160-6437-4c3b-8f6e-afef62f7bf83@yahoo.com> References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n> <46336160-6437-4c3b-8f6e-afef62f7bf83@yahoo.com> Feedback-ID: 45891198:user:proton X-Pm-Message-ID: 354d60cb5d7ab393ed7493a0f3792eb1496d3f1d 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:109.224.244.0/24, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dsjqh6hPlz3pTb On Thursday, January 15th, 2026 at 8:12 PM, Mark Millard wrote: >=20 >=20 > On 1/15/26 12:53, Minsoo Choo wrote: >=20 > > On Thursday, January 15th, 2026 at 2:22 PM, Shawn Webb shawn.webb@harde= nedbsd.org wrote: > >=20 > > Hi Shawn, > > . . . > >=20 > > > One question I have regarding the security posture of heterogeneous > > > cores is whether constant-time cryptographic/string/math/etc > > > operations take between cores. Would it be possible for an attacker t= o > > > do by virtue of the different types of cores? > >=20 > > ISA on different cores for a same chip is identical. For example, an Ar= m heterogeneous chip should provide same Arm ISA version (e.g. v9.3) rather= than different ISA for different cores. The scheduler has no idea on the I= SA version of a specific binary. >=20 >=20 > Hmm: https://www.nxp.com/docs/en/data-sheet/IMX7DCEC.pdf >=20 > looks to be a counter example, mixing a pair of Cortex-A7 CPUs and a > Cortex-M4 in the same SOC (my guess for "chip") --with separate > connections to the AXI and AHB Switch Fabric, sharing External Memory > and Internal Memory and everything else on that fabric. >=20 >From second page: "Arm Cortex-A7 plus Arm Cortex-M4=E2=80=94Heterogeneous M= ulticore Processing architecture enables the device to run an open operatin= g system like Linux/Android on the Cortex-A7 core and an RTOS like FreeRTOS= =E2=84=A2 on the Cortex-M4 core." This is not technically big.LITTLE. > The statement may be more of an indication of the bounds of the intended > support? Or of sub-setting which cores are involved for the FreeBSD > kernel? (Such also may not be as common for 64-bit contexts.) >=20 > Even with the same ISA, properties like cache line sizes can differ, > based on some example of such that I read about some time ago. (Not that > I could find the reference now.) Again: a point may be to avoid support > for such that ends up being "too odd" for the complexity to support it > vs. the normal range of uses for FreeBSD. For big.LITTLE, manufacturers cannot make any combinations of arm cores and= call it "heterogeneous". big and LITTLE cores have their pair since design= stage, such as A7-A15 and A53-A57. Wikipedia's page on ARM big.LITTLE [1] = shows three ways to arrange those cores for operating systems. My proposed = design is the third (and the latest) one called heterogeneous multi-process= ing (or HMP) which lets all cores to work concurrently. >=20 > > . . . > >=20 > > > -- > > > Shawn Webb > > > Cofounder / Security Engineer > > > HardenedBSD > > >=20 > > > Signal Username: shawn_webb.74 > > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_We= bb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc >=20 >=20 >=20 > -- > =3D=3D=3D > Mark Millard > marklmi at yahoo.com [1] https://en.wikipedia.org/wiki/ARM_big.LITTLE#Run-state_migration From nobody Fri Jan 16 04:37:21 2026 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 4dsnC16836z6NhXk for ; Fri, 16 Jan 2026 04:37:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dsnC141KFz44hL for ; Fri, 16 Jan 2026 04:37:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-8b29ff9d18cso198496085a.3 for ; Thu, 15 Jan 2026 20:37:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768538252; x=1769143052; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zTl6LP4mrW1ET/IMFnEWSFfPrhqnSyRW4kkqyI0X2gc=; b=BAna1Ig5Z9UPyHEhuUdpcpJhPARUWOyBeuqAS78Im/H3uy+9yJDxVTYLJPkgwr7F43 wJTk/A+oK5rpJ8NAuo0eEe6L6Cglrt1z/yjfCcoAF01KFskFOOPac4hPNaaRyj7WNVvV 6XT3maMxk8NeG0fTdVZ1xKAmcbTflwil5uW+DeoDR4ERBBHwTpx8vjGEQU+6qfaEDqBE JibUEd78dGQAh8z+m72SPga9cuJ1m1Y+ANERSdeOwSGanIEXnsiueZmmvLz1lznkv/th yP9/x0IRNK2XcYddLzAPYW5+58r0whT2eCDxfYGBA11TZBstMxtcaavsQLentUMjQKLS XhUg== X-Forwarded-Encrypted: i=1; AJvYcCV8qyoYbyYtwhqYDSNrpxkiPsvtmqyklYr182DUjlphaD+vvD1wBpZnV1WtB7a0b0lB7txlIuhwLeeTfi2xZ1Y=@freebsd.org X-Gm-Message-State: AOJu0YzouzM2osuqmKb3L3TYFiNoCfeCCOQvll6YncYpZRJO2q6Y3vv9 FSiq0Yh8CAmhjBpe1mQ7+44dIcr5Unzcd3MBoAxiUdlEadZA++/+CazR+J5hvXnE7+1+B1/1ch+ OoqKPw0CpRKqYfE4mdgpTUq+nQ/gC2bw= X-Gm-Gg: AY/fxX4ENrEFASErRtIGyOu1NzE/3dU4YMijyrQLFZbpl2OKiEhdnri5uf0/mCEiEfl gA6gLzyftihGR5v5VlMci2vBvqpBfMpcarHAWyEHPUndT5QFmyjFifAwh4kVRiXFZCOxfMTr/pz gAwo5ctTC3MQ3K4HCs9lLrtwMs+WCGBkbQFxtM5sCIwBpUzQE/JRCL79gWgj2tLIzlYBKQs5yxv ctQedZb748AJtIV7G65c6ZZucZGffUDjt9CSO6PWPXUowjVrA9h7zIeg89n4R+gnhyZJoR6u4iO n24P3Rc6l82ZV1pnCWluTmS9OKfvaQ/i5+SYOX3PoUJK+U+ODrUa1/oTtJtq X-Received: by 2002:ac8:5a03:0:b0:4ff:c14d:65cc with SMTP id d75a77b69052e-502a1758662mr26537211cf.51.1768538252278; Thu, 15 Jan 2026 20:37:32 -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: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n> <46336160-6437-4c3b-8f6e-afef62f7bf83@yahoo.com> In-Reply-To: From: Adrian Chadd Date: Thu, 15 Jan 2026 20:37:21 -0800 X-Gm-Features: AZwV_Qh0Jv1shrn5xSovRVm8pDyVgpq55HbtrsFG5xDdZYmb40QSeknjBbFH4EU Message-ID: Subject: Re: HMP scheduling on FreeBSD To: Minsoo Choo Cc: Mark Millard , Shawn Webb , freebsd-hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dsnC141KFz44hL On Thu, 15 Jan 2026 at 18:05, Minsoo Choo wrote: > > Hmm: https://www.nxp.com/docs/en/data-sheet/IMX7DCEC.pdf > > > > looks to be a counter example, mixing a pair of Cortex-A7 CPUs and a > > Cortex-M4 in the same SOC (my guess for "chip") --with separate > > connections to the AXI and AHB Switch Fabric, sharing External Memory > > and Internal Memory and everything else on that fabric. > > > > From second page: "Arm Cortex-A7 plus Arm Cortex-M4=E2=80=94Heterogeneous= Multicore Processing architecture enables the device to run an open operat= ing system like Linux/Android on the Cortex-A7 core and an RTOS like FreeRT= OS=E2=84=A2 on the Cortex-M4 core." This is not technically big.LITTLE. > Yeah. Linux has some memory FIFO/doorbell framework now for communication between chips on a shared AXI bus to support this style compute. Lots of vendors invented their own IPC layers for comms between MCUs, DSPs and the Cortex-A AP cores and then .. well, it's a mess. :-) > For big.LITTLE, manufacturers cannot make any combinations of arm cores a= nd call it "heterogeneous". big and LITTLE cores have their pair since desi= gn stage, such as A7-A15 and A53-A57. Wikipedia's page on ARM big.LITTLE [1= ] shows three ways to arrange those cores for operating systems. My propose= d design is the third (and the latest) one called heterogeneous multi-proce= ssing (or HMP) which lets all cores to work concurrently. There are systems shipping right now with three types of AP cores on one die. I've had to debug systems in the past with the big/little cores having different cache line sizes. It's a mess. Manufacturers will do whatever they can and patch linux to do whatever they need to. :-) I've also seen Linux software literally pass the output of "cat /proc/cpuinfo" to figure out this mess and then will do utterly baffling things like decide upon cache management, cpu workload scheduling, etc based on matching on the contents of said /proc/cpuinfo. I also believe there are some feature differences between the Intel power/efficiency cores? I haven't dug too deeply into it. That's why I'd like to figure out how to describe to userland and the rest of the kernel all these bits and pieces. The HMP stuff is a good move towards the scheduler side of stuff but I really don't want it wrapped up in some "the kernel will just do it magically" without letting some policy stuff be configured. -adrian From nobody Fri Jan 16 04:40:31 2026 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 4dsnGb4y5mz6Nhkh for ; Fri, 16 Jan 2026 04:40:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dsnGb0Flmz45PR for ; Fri, 16 Jan 2026 04:40:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768538435; bh=8U9NJyLEkq/L2SgtBGpZ/AHFWm4sHX8Z3Bl/qck//TI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=bWR8jOmseoPw5AejAgSLJTo4szgQeGQPsNhx3rEUrYKYBGGDLgK2E0fl6BuRlaqQ/TXHvtHt/hzo2Q8CVKOMmI+KHZD+KaJ+E/Uy6nZ8ZBl5TAbNVb1ah9Oiy5wHCNl2ypybJ+DdXaDD3ehxV1bRSGf1TiZJXKNav/BAJg+XmQxFUvEW4kL0sf9kq+zPguMipgRmiO/KegM1y4U1qaYLbQN8BomM1vH/iD3DyQ1DfbyiGF2UdFc+Za+VwhBBjmCyrWn03TlDVpULS9y1f1i/mqs8sOgrGT6n8/lJLNKthxXx5kKJ+/Dya/y+dFXt6oEPKVJgHZWvO0Bsdj6WfpMVtw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768538435; bh=SUSt2zfmXrU9UBsD/eBeP8qzKNLO136I+Cbt2Tfb/0s=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=tW6VGkMgUmpzGufjaPU+QNozHHDrjeIfJhNk7kajOjXeKIyQJ3jj9qFcK6bOGS0D+XdOkUREBErykIWg/VPn3GcYzKYVdMbOPckinFC1SKWbTYIRIRxGkMKcpGxBsotKJ6qrTSAG8Zsb3JqFmpKYpdo+CZu2p7t0M1v4RCUAV4sJ+AOsXoZi0Ksl1jYuH9SxQiyWN0ZTr3SzO6QJB6jbA110ajHCkoOkbTZW3fsiuV1YQwvby8bD9R/Bxuh1/2bd+Y5tZ4BKOvLSOokkUeH99Iti7SzuZPNE8Z0bZZb18q65klyS+NLSBJDXvSEm78Dp/PQIOCBOIbi3zj4o0noA0Q== X-YMail-OSG: RjxlmhYVM1mQd2iYaaZTmUDJ2fCb8KamvTncQKTpAodgv2QuKvnQyPVRjkxv3bc zjwfmGdm6_.kty2kGIGCk9W4DzelqxQOPwQprDntIcIV6t29H9hapfZAucgm.SY31xRukplMeLqv BNOVdJaCL.HUKII8QC.ktu3Yw6mSW.y7Oyc5dLUh5krTKKgubj3tak1oMTfRGOu6gJfRnqM69RTv n7b0pwtLbMK2SB35SkRTP03OT9Jhpv6NgzilmppCQ2UzGWxLXRiP5dl8Z4ssB55KGJ4qtv0gma0f W8EVp.Kdq10HojOI_fUEphtEWebLaEr7eZNg0TYEQXzSpIu0dwbyhdMn.tfUORMYpyNR0GlNwEfC tkWzOG3iKuMuVZ8RqtM5dSnjJyy.pNX8_5RS2OTzDlHE1WOi5aDyEFtFBA_VDOncCeEWybaTwR3J paZLt4cO.ht8ERAa8okY.Id7zAAnPx8v6WFq7AHOoYWcx3hv_7.RMKJerw62hz.NnMsMNiSaHe2o 6f1RwiFpaBmK_0uyKbKAWkICPohgK6zLlattOKvoNgkVIUJCFbHSjFzaCa7fkaTaeFRQm4VmUaPs qhBHKEEwykyDe9xJtefTn_zPypVsubJ_gHJqo7myGCJw_Lq2xdVn2.1_ThhYYfF9iB0MJRq_l3Sl 9Yuv7FKvFF7YQGagBvlJMTolMPNC1JVSXihqRaVRWeSAoesf8Olukv_o8pe9d5dxZ8inncVSJk67 Q0b6aiQveNKRB.Kct6r.FruFefEnlu_5k8FfTH7WuAkWCY.nHEHNQzAhqoCTClsjeC.Hq1A5bVe_ 3_ejNrUzEn3Ak6A_p7Clik7P4Jmfdy3e4lrPFb7Ouxa7IrmMSIY3oBQ46FpzijUNWf1Jaicnt5_l 3F7vjMPGEQHn4k3Gi9dV3xjCpXhQxhJO5Ga3p9.rjTU3V52yx7UxJ_F93p7Ugv8PkvRlVJOtgRWW J8vz5JV0HTGy4xY9b2gXV8PEwAudGZe8Tv7zDNmo7KLX0o1Fe95ynRgdHPDUySxMJoNbc2ew0SJ7 uCV0yvYVYEvoZrBlDoHaDER.OaiK9JsnleKz_nqJQ5tCxct0qBSA8uDgWBpYd78Stq1qiVxk3h7U _rmgCKomfKcdKSWRi64Oo3xecQnwZ58KbAnlzuj8lAit7uNw_11STXpNGfESlekzfuhjXybV3yef 6kjKXlWaz3CmTncw8HHtaOQONhTOiHMFV.KWjjLYSfdBtq1KRl1mTTkchEI7ByPUuqyT0UyvxILN iU_eAPOyHYQaO2.KBJfKJsEHfPdRajp5JHyPKhz252d_V_xBajZHmnNQVwHpHA8shm0Ra9sr1Ojf 8XyvcRk8eLZ.7VBvdxzdakA31KnMHcObSPe8FKxpjHpDs1_ijWJsPF32UFkT0tco2xq2Lm1WnlsV p4MQES2a9bJDa6rg.KCZwpQ6rYRsfYkCPQn6Ec8mueGkQFGg0GWjEbRitxSh9Teqp5nqg1KLUosd XOqYD5CeYJwpyMzn_EzUPb7dKaJTLYbZy7KIStN5wxepBiFTT.3BtbbWHkWW_OHW73bE7WyeP5po l7SJS2cmB9NnBom183FNFXSFPHL5HfR5lw3IuCH6391h_4b0e8vcl0yvSowVnccHltzPefvithFa 2D5g9z9eY2yJMzszJ.xxEkw2EwHescb_pAo9SrAq3tY4gIJbt2VsvWCLwTctkqQg7nxtI8M2rOiS YuQ4SovS36jtVLzM2_P.cs_7EL.HcKGTbLJl10KKBj37BQjWjoXlb_IxsVFyKOy_VXmMZPiSDOCq kbT.jPJPQTQAD7h1J0IQEvCSEvUxO25Wn0D1bLLKqjwd3TZ6VBG1CbeE8F_k_2.P9uuOVYunf7zW L46OUgmZUHvE_VoGD2yhXezJwSWOJbjkAJMPlWq.pvFXh2S7.s0rjyIHQUi.jeN6UvrJImKSCA59 z.Pm_d1QhHQQ5VLUBEntL48nAn.JHRrm9hri.HYQBjNFX1Mv3vlmoLnuOl_HHerfyRODprg2mAHF Ngz9ccR3SmWOxEUI6XGgthyG8LpFywUyYxtv2pJ7ozLmRB1hck6prLw6vXU8WXbV8r8qv5rtAM2t 2s8ik0loP0qCVMY4TlFSlo8mezIAaeT53hT.uQjchbKHUHsa6L5gL4BIEoiYhanushglIM9WdrOn 29bjiQd2dETMGgTkm.dXA8RRgDju0cz5lQusgrZ6rVFkA2ZD8ra7ZWlsfi9GKWiYsEAFgQvMGPqP GgqbISbGd6gB3HAdqG_l.SlqOTccsw6sdo6nBOkt6xl4eKRONWr1y9Qe.Vtr0mMZUUwJAW57X5Fg C0fX2Z3fioBjg3Js7pTCJ5lWUSRMOdlgUM8DpU8WtQg-- X-Sonic-MF: X-Sonic-ID: 59203824-2911-46f2-a7cd-f435677669c5 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Fri, 16 Jan 2026 04:40:35 +0000 Received: by hermes--production-gq1-86969b76cd-nvz7p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5e1709b2e0ad7d0c7a2b1b28312e5e69; Fri, 16 Jan 2026 04:40:32 +0000 (UTC) Message-ID: Date: Thu, 15 Jan 2026 20:40:31 -0800 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 User-Agent: Mozilla Thunderbird Subject: Re: HMP scheduling on FreeBSD To: Minsoo Choo Cc: Shawn Webb , freebsd-hackers Newsgroups: gmane.os.freebsd.devel.hackers References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n> <46336160-6437-4c3b-8f6e-afef62f7bf83@yahoo.com> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailer: WebService/1.1.24987 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dsnGb0Flmz45PR On 1/15/26 18:05, Minsoo Choo wrote: > On Thursday, January 15th, 2026 at 8:12 PM, Mark Millard wrote: > >> >> >> On 1/15/26 12:53, Minsoo Choo wrote: >> >>> On Thursday, January 15th, 2026 at 2:22 PM, Shawn Webb shawn.webb@hardenedbsd.org wrote: >>> >>> Hi Shawn, >>> . . . >>> >>>> One question I have regarding the security posture of heterogeneous >>>> cores is whether constant-time cryptographic/string/math/etc >>>> operations take between cores. Would it be possible for an attacker to >>>> do by virtue of the different types of cores? >>> >>> ISA on different cores for a same chip is identical. For example, an Arm heterogeneous chip should provide same Arm ISA version (e.g. v9.3) rather than different ISA for different cores. The scheduler has no idea on the ISA version of a specific binary. >> >> >> Hmm: https://www.nxp.com/docs/en/data-sheet/IMX7DCEC.pdf >> >> looks to be a counter example, mixing a pair of Cortex-A7 CPUs and a >> Cortex-M4 in the same SOC (my guess for "chip") --with separate >> connections to the AXI and AHB Switch Fabric, sharing External Memory >> and Internal Memory and everything else on that fabric. >> > > From second page: "Arm Cortex-A7 plus Arm Cortex-M4—Heterogeneous Multicore Processing architecture enables the device to run an open operating system like Linux/Android on the Cortex-A7 core and an RTOS like FreeRTOS™ on the Cortex-M4 core." This is not technically big.LITTLE. > >> The statement may be more of an indication of the bounds of the intended >> support? Or of sub-setting which cores are involved for the FreeBSD >> kernel? (Such also may not be as common for 64-bit contexts.) >> >> Even with the same ISA, properties like cache line sizes can differ, >> based on some example of such that I read about some time ago. (Not that >> I could find the reference now.) Again: a point may be to avoid support >> for such that ends up being "too odd" for the complexity to support it >> vs. the normal range of uses for FreeBSD. > > For big.LITTLE, manufacturers cannot make any combinations of arm cores and call it "heterogeneous". big and LITTLE cores have their pair since design stage, such as A7-A15 and A53-A57. Wikipedia's page on ARM big.LITTLE [1] shows three ways to arrange those cores for operating systems. My proposed design is the third (and the latest) one called heterogeneous multi-processing (or HMP) which lets all cores to work concurrently. Ahh, so "same chip" is really more of a big.LITTLE or DynamIQ "unit" of some kind (in arm terms). I'll note that for DynamIQ they started allowing a mix of big and little the same cluster, unlike before. It also allows having a mix of 3 types of cores, instead of just up to 2. QUOTE for: DynamIQ Shared Unit-AE Enabling DynamIQ for Armv8.2 AE CPUs, which enables a mixture of big and LITTLE CPUs to be configured in a single cluster. When Hybrid mode is enabled, DSU-AE supports up to 4 cores (big or LITTLE) in a single cluster, and up to 4MB L3. END QUOTE and: QUOTE for DynamIQ Shared Unit-120AE Enabling DynamIQ for Armv9.2 AE CPUs, with expanded support for up to 14 cores in a single cluster (with no additional restriction on the number of big or LITTLE cores) and up to 32MB L3 END QUOTE I see references to mixes of (picking ones with the A720 involved): A720/A520 Cix CD8180 A720/A520/X4 Qualcomm Snapdragon 8 Gen 3 (SM8650), Samsung Exynos 2400 A720/X4 MediaTek Dimensity 9300 A720/X4/X925 MediaTek Kompanio Ultra 910 (MT8196) While each may be internally uniform, across them there are variations in if the following are supported vs. not: ssbs (8.0), sve (8.2), svebf16 (8.2), svei8mm (8.2), paca (8.4), pacg (8.4), mte (8.5), mte3 (8.5), wfxt (8.7), sve2 (9.0), sveaes (9.0), svebitperm (9.0), svepmull (9.0), svesha3 (9.0), svesm4 (9.0). Even the 2 A720/A520/X4 instances appear to vary for: sve (8.2), svebf16 (8.2), sveei8mm (8.2), wfxt (8.7), sve2 (9.0), sveaes (9.0), svebitperm (9.0), svepmull (9.0), svesha3 (9.0), svesm4 (9.0). (The lists may not be complete.) That gives me a better idea what you were being referred to, at least in an arm context. Thanks. > >> >>> . . . >>> >>>> -- >>>> Shawn Webb >>>> Cofounder / Security Engineer >>>> HardenedBSD >>>> >>>> Signal Username: shawn_webb.74 >>>> Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 >>>> https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc >> >> >> >> -- >> === >> Mark Millard >> marklmi at yahoo.com > > [1] https://en.wikipedia.org/wiki/ARM_big.LITTLE#Run-state_migration > > -- === Mark Millard marklmi at yahoo.com From nobody Fri Jan 16 05:01:31 2026 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 4dsnkv2zGqz6NkGD for ; Fri, 16 Jan 2026 05:01:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dsnkt6d7Xz47qp for ; Fri, 16 Jan 2026 05:01:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768539694; bh=1hDna5LU0NnQJm8E1C8LCfcJPAYd1ZOXOmvA6Lan/5A=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=PVMC8m7jQBNce5du+v6xEx1wgYUw5+YB1wDh0HNHWB8pOHDQIjFo+WH+x1qtNnbdAqYxTPcyI33SkVQjhnxtOkg6saERqPVwn5f7uSjpI7ycDeKf2dUypZpPpDf/sEGjLTGPncN/FvWsB2xhuhkVA4/XtU+6sKGH/PsU7Z5/AxeKQ+cr+as2xRd+caJ5U/C/5PtnbI0EWD6EXrRhFjSm+DcD7dphmOqs09sCZFr+STBdjB697VeiCokvlasW28hQc81ilKv43vUv4WtxuQMXplI90G9S/SmEpaWPZq1khivEF9FgU3d0kuUIB3SFL+GeKDicYhihGpAMQyDCwmV0lA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1768539694; bh=sEbzG2r8d1iI0+qC2UJ3IpYAeAcfRVLwjzw//2h9x9y=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=LdgxqBZpY+urfCnd0SmbRK/ZBWsRZyDvuQXVHHNgC7pt3HEdmfO38+yaxVJYqfGL60jTqvcMkWHbVcyCfLo/gYWwk9y5i72/8pdTLXwpSBmKE6YX49mn8kf3QN5PwkMuaDRAyD7GwSREEz15CDqbTzbMXWArVttPeYJJFL/Z96n/SnFMHE++RBESaCgFT97At3W5HdNt1XQFUsuiNE314PJDTUWvdmSMoc00HVWdJO3LuJuO8u7aefAuwkmiOo1Tw28ztmDoOX60urNs02VMJGk9j9zmGRvokpcRsDjl5V+1Nha8KprRPUlrLqtbCiQp8ZOddHbFhUlq/RHzlgEkdA== X-YMail-OSG: Pu8gd.0VM1lbQT54cemu5k2mHUqzV7BKqsMyzXDfrmK7gFyQYfC.ms4cn9Q8gkP azmhT3ePrQL6rtCqVuDfZXkouNjWDRtBkFiK5ZiB6HeadGAFQTgLzkRJOllQgrIMG7FW2aDpQf_U 7kIOeODkcYLTNKBsfVvdyR4rrwaG3LFQXxh7zONTmA8HMebA090nmkPzASxmumfXWjLSowAK.HYY We2u35Sq4o0BCOoLNCM1JYQj4nxc55ox3IqdSPQPI.WVokU8jZJP4K3nFEkacpvNz0hVwdCMO_Hw 8ahvUd1mJufc3zF8tE5SS_Mj6Q3KyKTk9k5c5NHC7kIMVY9SahqfuUxbl4AZ4129mV0j5UQRL7fH kA9Xt7bTszx.fR5BmpyZqlZQDuu1Kn3xXQFFca7sEd0io_.jujk3q4xsQPpihvR0gFdje8BBgQbz T_iTJwERKQpAVmaON5.kRAqEFlMWg68gdMV1zu3fdzsOgAL5XRkzgQwZ69CF74WSoqmxeEODRXoK 8aJZLRABTDUFLF8oHSmDM.oODy8vjuDR_3Z6d5dvF7RhGDEw1QsgmVC2BaSvm0ldheDv5bR5pXR1 Nm9iW.vvWiy66ZXgH3t7Ba.8zy5L_bbKTH.EFX45kj_hqKz4EEB4VTM6TzCUfzE9D.sN7Wh5k4pF 9MI_DbB4lgQ.40tS25JJGuvYx6.t_saeJ25zlVrFTgmEe.UpKlEtuwcbsNZEToPBdpCpUeVLvhFI .OFjx.cIyWmmp1LWb25b8X.84jrf195XxdRXWY_2eXrAUfKJOzlFrEpFuuAWfn1UkTds1TrTJjR. TePs5f1Cy1Nw2VFHEo09Yo_dFaNscQtgUt6dAuZ.C3kRnRnEKdHIRrYJDAIzucBJMco3R3L75rXs 4UcMgqQMNcryat_Q9OX4v6yMXTiE5QQMa.L8CxkAOGJs23jELjWmNUXax3POaithRtPCCI7hvhCj BQ1I9EyzWN4YEg3WBI7G6bvSmPasqEDYOvxS1A4tQPa4AD5y8OHjbRoQzdIf_n3HEkJtrz9qvy7M RuuHIOa8txZzsXrRn_ScRKUhSfdtTzwMeWHU6MrvztpfA0S8E.0vpiok_7JYluAA17Xufla2voGM CIewaWv2gzn9KM4U2HEsc0_cIPynbjU1bGnHZkBX.N1OasQeXvN_5.FL2C7eJ.At_nzTRBji_Q_V sEuCW4KPz3_cNH.qNuAl1Oap3iCLItYEurO.Gwdej9ijEQ9mSiO8WFGb7ftvvQQC_2GyhuUDQKId gR6y3_Qq4CEV_ZcDys3X1uRH17sMAmtyIhPcw8yiMNSpMaRtvumWdVqAASLvjIhgKumR3R0VBzmu 4dOtDCB25kFbrzypTIUw9uGsrzqGoXUPDCAziOvWp2Nid5pqwMu8z9lFFMHp3QsnemEGUNuXHVcW jWSDP13zl.oUi_HJbuExKZwZQ2unNkn_UBuP_Tkg7UKNUqwRS3Z8.Zb80aaX2Uu5seYZjKy0RtrJ R0yh52H1AdxdK5ETcWNQIVhJNWuYy4a27Ad5K61JmPppauXWOpOkhWCKGy9TzlpQAjMR68mE71x. ylOs5L7B1_kru5qpGfodMA1I68yvipsC6OdOrevmCMPI6w.t5IzaDrfPnE0O7eYbjl2NbKk61XV. _pk_Q0uLSiNooNYcH_oPF1RP7VMClARsGhMkb8JXk69741MC1OGP4zmvj0zCJbs5OmxkUrY1LjGR Ox7w.Ly0r5rrubfrZev5wawBzzbXCjkFdIAVw3ppwwC8ou3nucj9KzzwXndsCCmfoLHJ537BihgD 2lPtEDce7aJZR1C2lzcDpwypeLo5dG8quGM8Ez61.IuxD4wq5SoVJtcvsP1UoFDEFeryzXdhut7I AwHdr4n2uCavp7uVjpR36BquJSvf5BHo9U.GuCh12M7c1fi219PIGp6lgXq2lPM5W4AzhT8z.e3G br.r18_j8WGIl.YvgnL45CxUzdB0EYfEYEWfeDwE.mO8qAVXjEJzPZXhVXHFdxowP9uR_H19W.1t 1S9lMOF1FJqYQovDJGzmJqXVnL0jhAnGoTsmP0kryjVPt58ETETnev.3m1a3Yyz4RKZsvc3ztaQY li06ScbXIP_lu3EqjgXyjhK59CNAR3bVCJSnF2zQxQL_MzJCmj7.aKGTdQpwS9nkuEsDUEl8Tw05 bTXoF67dEE50i8JO9pUuQo4YGLb1_OBa_7awIOrrgo.9W30ANFU9_aNx09VO52iuqPhmuFixBUD0 _nh4ruTuFl3KG5S0Lr99vg7G709KUVVUMPj1lc7WKgZspu9.wLjNyCXJdxUeTbcngOn023eJ.vt6 WcSpu3pP9Iu9ITYxf56ui7d0GhzGJ9w-- X-Sonic-MF: X-Sonic-ID: 547d2ffa-d302-4048-9fcb-51470a687ee9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 16 Jan 2026 05:01:34 +0000 Received: by hermes--production-gq1-86969b76cd-q5xns (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5d1bf74c299e730fa1cb2bade398987c; Fri, 16 Jan 2026 05:01:32 +0000 (UTC) Message-ID: <3ecaed80-f609-409f-b86c-900b0165ca5c@yahoo.com> Date: Thu, 15 Jan 2026 21:01:31 -0800 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 User-Agent: Mozilla Thunderbird Subject: Re: HMP scheduling on FreeBSD To: Adrian Chadd , Minsoo Choo Cc: Shawn Webb , freebsd-hackers References: <0Ng09S3rEB0BvT9vzHqVKU7rWxoad96kjEc7U2LCwDFJKmmswXujip7qbRlo_BIhNKcI7d-2CUHdp9Dxr3-7hhafpD6uagJSFUCjtC9qRr4=@proton.me> <5a2sxxiqkafxdolq362ivmpyfemi5wc75zknnuzqdhstezumrq@2p7o2dmf7r6n> <46336160-6437-4c3b-8f6e-afef62f7bf83@yahoo.com> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.24987 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dsnkt6d7Xz47qp On 1/15/26 20:37, Adrian Chadd wrote: > . . . > > There are systems shipping right now with three types of AP cores on > one die. I've had to debug systems in the past with the big/little > cores having > different cache line sizes. It's a mess. Manufacturers will do > whatever they can and patch linux to do whatever they need to. :-) > > I've also seen Linux software literally pass the output of "cat > /proc/cpuinfo" to figure out this mess and then will do utterly > baffling things > like decide upon cache management, cpu workload scheduling, etc based > on matching on the contents of said /proc/cpuinfo. Hmm. As I remember, possibly incorrectly, I once had to look up how something worked for /proc/cpuinfo and it turned out what I was looking for was something that was not (yet?) set up to be handled. So /proc/cpuinfo reported the feature as not available when it fact it was indicated as possible by the original bits: more of an 'are things ready for this to be used' than a 'this is what the original bits report about the core'. I've no clue how common such may be. > > I also believe there are some feature differences between the Intel > power/efficiency cores? I haven't dug too deeply into it. > > That's why I'd like to figure out how to describe to userland and the > rest of the kernel all these bits and pieces. > The HMP stuff is a good move towards the scheduler side of stuff but I > really don't want it wrapped up in some > "the kernel will just do it magically" without letting some policy > stuff be configured. > > > -adrian > > -- === Mark Millard marklmi at yahoo.com From nobody Fri Jan 16 07:55:00 2026 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 4dssbh38BQz6Nvlw for ; Fri, 16 Jan 2026 07:55:44 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dssbg3lQSz3PHb for ; Fri, 16 Jan 2026 07:55:43 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=WyIbc4KG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cedric.blancher@gmail.com designates 2001:4860:4864:20::36 as permitted sender) smtp.mailfrom=cedric.blancher@gmail.com Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-4041c73ab4dso657740fac.2 for ; Thu, 15 Jan 2026 23:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768550136; x=1769154936; darn=freebsd.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rkBKQl8y+F+XNknJAVdjIIM32iwydsMCVyAjZwb5tdc=; b=WyIbc4KG0x/PBU6kYYh6CG1CoL1UsyAPcgLkXBxZAH3dbFd/aTkL1RlumURWJVMKn1 Hasw6eZAGy3OEuIdDcGb7kegM9FpA7RplpoQY7GoRfPNcQ7u68LNuGWRJhn/Y8CJb1Yo ipi7ACvtSMfHzjqzdOoTS0z0tSp/syHDuzMIy/sCv6hAcgcX2Om0VoNfarMYLn71lsp1 ICfWGXA1y2LtclrUJVkYXJf0SsyMr1xvTN/N+LzhMlAdxrSnKPiJf2DFIvHfjm6ZkbhI LUHZmkq64kBP+yPEl/fzyHehjKtFzfKC146+qfRVApLdIJYHtbuy6r0x1hwUC98U6Etw nZJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768550136; x=1769154936; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=rkBKQl8y+F+XNknJAVdjIIM32iwydsMCVyAjZwb5tdc=; b=hFc8YMkbqiC4lXs2CKEidxzwSwbRw1wOfz7kqGUSwlAJR7ynjeAczA9+3SmIOGF5tR ebsOfIJpnlZwMlNWxLXo+rcMvLbNjt/SPMJGO0HaL1Y7jFQSRvEstr1YLEqNNQsZbzSf dBSjuwuAi1fBkICT+VR0OHM8u+JHgYNbWKXmjpdAY7Y2793rSB7dlP1aKH+XnK4XstPD wneOhXEnm6b0X1YNIShmvoEs188qO3oy5AbZksCDlTmlLQp7A3w2xG54bj+y0y3gpnU5 48l45qy3oM2yisKIEdNhy7F+ozmQI9VMbvYnIHHSWDKNX5WvV9SvdQ5a7nOBLkgPyAcn ZlgA== X-Gm-Message-State: AOJu0YzJO9Hrk2TdA5h2VOGoDGgz+SfUq3b8susVVSM7buk8NEJr+FmD bM8s0HlkGA8W7Phyu1VOXEz2lhLlXUM/aepdbGiKSYtZ21QkRBHYNqkBJW4FRb693vFMNBUNGfN zzOcNaTFWGQK28l6dplDd7FqhGJTpfjKOKw== X-Gm-Gg: AY/fxX4tPUp6TAvtBAXt0oc5ltDs7RirgsUWVOJrxRNRIq5vZ5cdMPokC7Fva4vZYBi 8+v3G0g86YI47cQqgLhHMDilUYg/vjYjSvLYQedL1iLnlfYUdgxZKq8omDdf6w4VmoMwDdpvIVs rZUxwZzeYl554IGgeZZEElMjTUf+9Jc7+Ui8FnytkRCu0ZCcIzLAnB9S8mGtqXOEIyEAIrFPEhz m3j808QD5RzMrOMkewEXppKLgBySHBsAZi22MbpszS2n0FfX1uWnacX1Y2O0J1MktqCRAIkK7jg OyMeLQ== X-Received: by 2002:a05:6820:2906:b0:660:ff2c:d76f with SMTP id 006d021491bc7-661189a0f58mr820592eaf.80.1768550136450; Thu, 15 Jan 2026 23:55:36 -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: In-Reply-To: From: Cedric Blancher Date: Fri, 16 Jan 2026 08:55:00 +0100 X-Gm-Features: AZwV_QiCm-lbMZYvMX4ltcd7rXS2AdHhvHifxaEULo0bdhvuWPQ4SAylc0i5yIc Message-ID: Subject: Re: FreeBSD NFSv4.1 *CLIENT* - case insensitive filesystems supported? Re: FreeBSD NFSv4.1 client and server - case insensitive filesystems supported? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4dssbg3lQSz3PHb On Mon, 12 Jan 2026 at 23:04, Rick Macklem wrote: > > On Mon, Jan 12, 2026 at 1:56=E2=80=AFPM Rick Macklem wrote: > > > > On Mon, Jan 12, 2026 at 11:52=E2=80=AFAM Cedric Blancher > > wrote: > > > > > > Good evening! > > > > > > Does the FreeBSD >=3D 14.3 NFSv4.1 client and server support case > > > insensitive filesystems, e.g. exported ZFS or FAT? > > Greater than, as in 15.0. > Oops, that's 15.1-> > (I looked and it is in stable/15, but not releng/15.0.) > (I work with main and the stable branches and don't keep track of when th= e > releases branch off.) What about the FreeBSD 15.x NFSv4.2 client - does it support case-insensitive filesystems? Ced --=20 Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur