From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBC47C77B6E for ; Wed, 12 Apr 2023 17:27:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229696AbjDLR1T (ORCPT ); Wed, 12 Apr 2023 13:27:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36764 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229484AbjDLR1S (ORCPT ); Wed, 12 Apr 2023 13:27:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E78D440FB; Wed, 12 Apr 2023 10:27:16 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 829B0634C9; Wed, 12 Apr 2023 17:27:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DA85C433EF; Wed, 12 Apr 2023 17:27:11 +0000 (UTC) Date: Wed, 12 Apr 2023 18:27:08 +0100 From: Catalin Marinas To: Justin Forbes Cc: Mike Rapoport , Andrew Morton , Arnd Bergmann , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Geert Uytterhoeven , Guo Ren , John Paul Adrian Glaubitz , "Kirill A. Shutemov" , Max Filippov , Michael Ellerman , Rich Felker , Russell King , Will Deacon , Yoshinori Sato , Zi Yan , linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mm@kvack.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org Subject: Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-ID: References: <20230325060828.2662773-1-rppt@kernel.org> <20230325060828.2662773-3-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-csky@vger.kernel.org On Tue, Apr 04, 2023 at 06:50:01AM -0500, Justin Forbes wrote: > On Tue, Apr 4, 2023 at 2:22 AM Mike Rapoport wrote: > > On Wed, Mar 29, 2023 at 10:55:37AM -0500, Justin Forbes wrote: > > > On Sat, Mar 25, 2023 at 1:09 AM Mike Rapoport wrote: > > > > > > > > From: "Mike Rapoport (IBM)" > > > > > > > > It is not a good idea to change fundamental parameters of core memory > > > > management. Having predefined ranges suggests that the values within > > > > those ranges are sensible, but one has to *really* understand > > > > implications of changing MAX_ORDER before actually amending it and > > > > ranges don't help here. > > > > > > > > Drop ranges in definition of ARCH_FORCE_MAX_ORDER and make its prompt > > > > visible only if EXPERT=y > > > > > > I do not like suddenly hiding this behind EXPERT for a couple of > > > reasons. Most importantly, it will silently change the config for > > > users building with an old kernel config. If a user has for instance > > > "13" set and building with 4K pages, as is the current configuration > > > for Fedora and RHEL aarch64 builds, an oldconfig build will now set it > > > to 10 with no indication that it is doing so. And while I think that > > > 10 is a fine default for many aarch64 users, there are valid reasons > > > for choosing other values. Putting this behind expert makes it much > > > less obvious that this is an option. > > > > That's the idea of EXPERT, no? > > > > This option was intended to allow allocation of huge pages for > > architectures that had PMD_ORDER > MAX_ORDER and not to allow user to > > select size of maximal physically contiguous allocation. > > > > Changes to MAX_ORDER fundamentally change the behaviour of core mm and > > unless users *really* know what they are doing there is no reason to choose > > non-default values so hiding this option behind EXPERT seems totally > > appropriate to me. > > It sounds nice in theory. In practice. EXPERT hides too much. When you > flip expert, you expose over a 175ish new config options which are > hidden behind EXPERT. You don't have to know what you are doing just > with the MAX_ORDER, but a whole bunch more as well. If everyone were > already running 10, this might be less of a problem. At least Fedora > and RHEL are running 13 for 4K pages on aarch64. This was not some > accidental choice, we had to carry a patch to even allow it for a > while. If this does go in as is, we will likely just carry a patch to > remove the "if EXPERT", but that is a bit of a disservice to users who > might be trying to debug something else upstream, bisecting upstream > kernels or testing a patch. In those cases, people tend to use > pristine upstream sources without distro patches to verify, and they > tend to use their existing configs. With this change, their MAX_ORDER > will drop to 10 from 13 silently. That can look like a different > issue enough to ruin a bisect or have them give bad feedback on a > patch because it introduces a "regression" which is not a regression > at all, but a config change they couldn't see. If we remove EXPERT (as prior to this patch), I'd rather keep the ranges and avoid having to explain to people why some random MAX_ORDER doesn't build (keeping the range would also make sense for randconfig, not sure we got to any conclusion there). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Date: Wed, 12 Apr 2023 17:27:08 +0000 Subject: Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-Id: List-Id: References: <20230325060828.2662773-1-rppt@kernel.org> <20230325060828.2662773-3-rppt@kernel.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Justin Forbes Cc: Mike Rapoport , Andrew Morton , Arnd Bergmann , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Geert Uytterhoeven , Guo Ren , John Paul Adrian Glaubitz , "Kirill A. Shutemov" , Max Filippov , Michael Ellerman , Rich Felker , Russell King , Will Deacon , Yoshinori Sato , Zi Yan , linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mm@kvack.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org On Tue, Apr 04, 2023 at 06:50:01AM -0500, Justin Forbes wrote: > On Tue, Apr 4, 2023 at 2:22 AM Mike Rapoport wrote: > > On Wed, Mar 29, 2023 at 10:55:37AM -0500, Justin Forbes wrote: > > > On Sat, Mar 25, 2023 at 1:09 AM Mike Rapoport wrote: > > > > > > > > From: "Mike Rapoport (IBM)" > > > > > > > > It is not a good idea to change fundamental parameters of core memory > > > > management. Having predefined ranges suggests that the values within > > > > those ranges are sensible, but one has to *really* understand > > > > implications of changing MAX_ORDER before actually amending it and > > > > ranges don't help here. > > > > > > > > Drop ranges in definition of ARCH_FORCE_MAX_ORDER and make its prompt > > > > visible only if EXPERT=y > > > > > > I do not like suddenly hiding this behind EXPERT for a couple of > > > reasons. Most importantly, it will silently change the config for > > > users building with an old kernel config. If a user has for instance > > > "13" set and building with 4K pages, as is the current configuration > > > for Fedora and RHEL aarch64 builds, an oldconfig build will now set it > > > to 10 with no indication that it is doing so. And while I think that > > > 10 is a fine default for many aarch64 users, there are valid reasons > > > for choosing other values. Putting this behind expert makes it much > > > less obvious that this is an option. > > > > That's the idea of EXPERT, no? > > > > This option was intended to allow allocation of huge pages for > > architectures that had PMD_ORDER > MAX_ORDER and not to allow user to > > select size of maximal physically contiguous allocation. > > > > Changes to MAX_ORDER fundamentally change the behaviour of core mm and > > unless users *really* know what they are doing there is no reason to choose > > non-default values so hiding this option behind EXPERT seems totally > > appropriate to me. > > It sounds nice in theory. In practice. EXPERT hides too much. When you > flip expert, you expose over a 175ish new config options which are > hidden behind EXPERT. You don't have to know what you are doing just > with the MAX_ORDER, but a whole bunch more as well. If everyone were > already running 10, this might be less of a problem. At least Fedora > and RHEL are running 13 for 4K pages on aarch64. This was not some > accidental choice, we had to carry a patch to even allow it for a > while. If this does go in as is, we will likely just carry a patch to > remove the "if EXPERT", but that is a bit of a disservice to users who > might be trying to debug something else upstream, bisecting upstream > kernels or testing a patch. In those cases, people tend to use > pristine upstream sources without distro patches to verify, and they > tend to use their existing configs. With this change, their MAX_ORDER > will drop to 10 from 13 silently. That can look like a different > issue enough to ruin a bisect or have them give bad feedback on a > patch because it introduces a "regression" which is not a regression > at all, but a config change they couldn't see. If we remove EXPERT (as prior to this patch), I'd rather keep the ranges and avoid having to explain to people why some random MAX_ORDER doesn't build (keeping the range would also make sense for randconfig, not sure we got to any conclusion there). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C73EBC7619A for ; Wed, 12 Apr 2023 17:27:50 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4PxV5x1XZTz3fSc for ; Thu, 13 Apr 2023 03:27:49 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=cmarinas@kernel.org; receiver=) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4PxV5L5W57z3chn for ; Thu, 13 Apr 2023 03:27:18 +1000 (AEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7DEAC63282; Wed, 12 Apr 2023 17:27:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DA85C433EF; Wed, 12 Apr 2023 17:27:11 +0000 (UTC) Date: Wed, 12 Apr 2023 18:27:08 +0100 From: Catalin Marinas To: Justin Forbes Subject: Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-ID: References: <20230325060828.2662773-1-rppt@kernel.org> <20230325060828.2662773-3-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rich Felker , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Max Filippov , Guo Ren , linux-csky@vger.kernel.org, sparclinux@vger.kernel.org, Will Deacon , Yoshinori Sato , Russell King , Geert Uytterhoeven , Zi Yan , linux-xtensa@linux-xtensa.org, Arnd Bergmann , linux-m68k@lists.linux-m68k.org, John Paul Adrian Glaubitz , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dinh Nguyen , Mike Rapoport , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" , "Kirill A. Shutemov" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Apr 04, 2023 at 06:50:01AM -0500, Justin Forbes wrote: > On Tue, Apr 4, 2023 at 2:22 AM Mike Rapoport wrote: > > On Wed, Mar 29, 2023 at 10:55:37AM -0500, Justin Forbes wrote: > > > On Sat, Mar 25, 2023 at 1:09 AM Mike Rapoport wrote: > > > > > > > > From: "Mike Rapoport (IBM)" > > > > > > > > It is not a good idea to change fundamental parameters of core memory > > > > management. Having predefined ranges suggests that the values within > > > > those ranges are sensible, but one has to *really* understand > > > > implications of changing MAX_ORDER before actually amending it and > > > > ranges don't help here. > > > > > > > > Drop ranges in definition of ARCH_FORCE_MAX_ORDER and make its prompt > > > > visible only if EXPERT=y > > > > > > I do not like suddenly hiding this behind EXPERT for a couple of > > > reasons. Most importantly, it will silently change the config for > > > users building with an old kernel config. If a user has for instance > > > "13" set and building with 4K pages, as is the current configuration > > > for Fedora and RHEL aarch64 builds, an oldconfig build will now set it > > > to 10 with no indication that it is doing so. And while I think that > > > 10 is a fine default for many aarch64 users, there are valid reasons > > > for choosing other values. Putting this behind expert makes it much > > > less obvious that this is an option. > > > > That's the idea of EXPERT, no? > > > > This option was intended to allow allocation of huge pages for > > architectures that had PMD_ORDER > MAX_ORDER and not to allow user to > > select size of maximal physically contiguous allocation. > > > > Changes to MAX_ORDER fundamentally change the behaviour of core mm and > > unless users *really* know what they are doing there is no reason to choose > > non-default values so hiding this option behind EXPERT seems totally > > appropriate to me. > > It sounds nice in theory. In practice. EXPERT hides too much. When you > flip expert, you expose over a 175ish new config options which are > hidden behind EXPERT. You don't have to know what you are doing just > with the MAX_ORDER, but a whole bunch more as well. If everyone were > already running 10, this might be less of a problem. At least Fedora > and RHEL are running 13 for 4K pages on aarch64. This was not some > accidental choice, we had to carry a patch to even allow it for a > while. If this does go in as is, we will likely just carry a patch to > remove the "if EXPERT", but that is a bit of a disservice to users who > might be trying to debug something else upstream, bisecting upstream > kernels or testing a patch. In those cases, people tend to use > pristine upstream sources without distro patches to verify, and they > tend to use their existing configs. With this change, their MAX_ORDER > will drop to 10 from 13 silently. That can look like a different > issue enough to ruin a bisect or have them give bad feedback on a > patch because it introduces a "regression" which is not a regression > at all, but a config change they couldn't see. If we remove EXPERT (as prior to this patch), I'd rather keep the ranges and avoid having to explain to people why some random MAX_ORDER doesn't build (keeping the range would also make sense for randconfig, not sure we got to any conclusion there). -- Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3AE5FC77B6E for ; Wed, 12 Apr 2023 17:28:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dk4OCSMvrDNLjso5fNmQ7M3gM1HTYFcs8p6MT6ETAx8=; b=Hi3g8CLL5rvrmA xiOZUecOfWJ9bF9onqcMEvHGDTDArVacSTJ1Br5wXcYLNkdJc2rPXpQl9P6OeBXUnQ7aL1TL4QfvN 7LI2tJHZJcWsNm85upMCArEzDP8DMdG7bjCgo8a7Bz2CYOQZOp4Y2t1c9Hi0kvj2XuIpKdgrEkvcS pvBi08MCk0QtorTCiPQ5+UuRrdFfhrlQXFA+scpra9P06q85PuLUeMaENHwnC0DM1t/5qU2Cqdm3H wV4v9dV5Ykho74+LnbIsZPFqRLBLYGfarIiHRFQ7hNHJ90HcMbm5pP/bcaEtn82FAsnIjniycdKKz uKT3KQEyZrFvlT1WEgiw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmeFc-003yB6-2H; Wed, 12 Apr 2023 17:27:20 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pmeFY-003yAN-37 for linux-arm-kernel@lists.infradead.org; Wed, 12 Apr 2023 17:27:18 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7DEAC63282; Wed, 12 Apr 2023 17:27:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DA85C433EF; Wed, 12 Apr 2023 17:27:11 +0000 (UTC) Date: Wed, 12 Apr 2023 18:27:08 +0100 From: Catalin Marinas To: Justin Forbes Cc: Mike Rapoport , Andrew Morton , Arnd Bergmann , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Geert Uytterhoeven , Guo Ren , John Paul Adrian Glaubitz , "Kirill A. Shutemov" , Max Filippov , Michael Ellerman , Rich Felker , Russell King , Will Deacon , Yoshinori Sato , Zi Yan , linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mm@kvack.org, linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org Subject: Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER Message-ID: References: <20230325060828.2662773-1-rppt@kernel.org> <20230325060828.2662773-3-rppt@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230412_102717_107308_840C924D X-CRM114-Status: GOOD ( 43.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gVHVlLCBBcHIgMDQsIDIwMjMgYXQgMDY6NTA6MDFBTSAtMDUwMCwgSnVzdGluIEZvcmJlcyB3 cm90ZToKPiBPbiBUdWUsIEFwciA0LCAyMDIzIGF0IDI6MjLigK9BTSBNaWtlIFJhcG9wb3J0IDxy cHB0QGtlcm5lbC5vcmc+IHdyb3RlOgo+ID4gT24gV2VkLCBNYXIgMjksIDIwMjMgYXQgMTA6NTU6 MzdBTSAtMDUwMCwgSnVzdGluIEZvcmJlcyB3cm90ZToKPiA+ID4gT24gU2F0LCBNYXIgMjUsIDIw MjMgYXQgMTowOeKAr0FNIE1pa2UgUmFwb3BvcnQgPHJwcHRAa2VybmVsLm9yZz4gd3JvdGU6Cj4g PiA+ID4KPiA+ID4gPiBGcm9tOiAiTWlrZSBSYXBvcG9ydCAoSUJNKSIgPHJwcHRAa2VybmVsLm9y Zz4KPiA+ID4gPgo+ID4gPiA+IEl0IGlzIG5vdCBhIGdvb2QgaWRlYSB0byBjaGFuZ2UgZnVuZGFt ZW50YWwgcGFyYW1ldGVycyBvZiBjb3JlIG1lbW9yeQo+ID4gPiA+IG1hbmFnZW1lbnQuIEhhdmlu ZyBwcmVkZWZpbmVkIHJhbmdlcyBzdWdnZXN0cyB0aGF0IHRoZSB2YWx1ZXMgd2l0aGluCj4gPiA+ ID4gdGhvc2UgcmFuZ2VzIGFyZSBzZW5zaWJsZSwgYnV0IG9uZSBoYXMgdG8gKnJlYWxseSogdW5k ZXJzdGFuZAo+ID4gPiA+IGltcGxpY2F0aW9ucyBvZiBjaGFuZ2luZyBNQVhfT1JERVIgYmVmb3Jl IGFjdHVhbGx5IGFtZW5kaW5nIGl0IGFuZAo+ID4gPiA+IHJhbmdlcyBkb24ndCBoZWxwIGhlcmUu Cj4gPiA+ID4KPiA+ID4gPiBEcm9wIHJhbmdlcyBpbiBkZWZpbml0aW9uIG9mIEFSQ0hfRk9SQ0Vf TUFYX09SREVSIGFuZCBtYWtlIGl0cyBwcm9tcHQKPiA+ID4gPiB2aXNpYmxlIG9ubHkgaWYgRVhQ RVJUPXkKPiA+ID4KPiA+ID4gSSBkbyBub3QgbGlrZSBzdWRkZW5seSBoaWRpbmcgdGhpcyBiZWhp bmQgRVhQRVJUIGZvciBhIGNvdXBsZSBvZgo+ID4gPiByZWFzb25zLiAgTW9zdCBpbXBvcnRhbnRs eSwgaXQgd2lsbCBzaWxlbnRseSBjaGFuZ2UgdGhlIGNvbmZpZyBmb3IKPiA+ID4gdXNlcnMgYnVp bGRpbmcgd2l0aCBhbiBvbGQga2VybmVsIGNvbmZpZy4gIElmIGEgdXNlciBoYXMgZm9yIGluc3Rh bmNlCj4gPiA+ICIxMyIgc2V0IGFuZCBidWlsZGluZyB3aXRoIDRLIHBhZ2VzLCBhcyBpcyB0aGUg Y3VycmVudCBjb25maWd1cmF0aW9uCj4gPiA+IGZvciBGZWRvcmEgYW5kIFJIRUwgYWFyY2g2NCBi dWlsZHMsIGFuIG9sZGNvbmZpZyBidWlsZCB3aWxsIG5vdyBzZXQgaXQKPiA+ID4gdG8gMTAgd2l0 aCBubyBpbmRpY2F0aW9uIHRoYXQgaXQgaXMgZG9pbmcgc28uICBBbmQgd2hpbGUgSSB0aGluayB0 aGF0Cj4gPiA+IDEwIGlzIGEgZmluZSBkZWZhdWx0IGZvciBtYW55IGFhcmNoNjQgdXNlcnMsIHRo ZXJlIGFyZSB2YWxpZCByZWFzb25zCj4gPiA+IGZvciBjaG9vc2luZyBvdGhlciB2YWx1ZXMuIFB1 dHRpbmcgdGhpcyBiZWhpbmQgZXhwZXJ0IG1ha2VzIGl0IG11Y2gKPiA+ID4gbGVzcyBvYnZpb3Vz IHRoYXQgdGhpcyBpcyBhbiBvcHRpb24uCj4gPgo+ID4gVGhhdCdzIHRoZSBpZGVhIG9mIEVYUEVS VCwgbm8/Cj4gPgo+ID4gVGhpcyBvcHRpb24gd2FzIGludGVuZGVkIHRvIGFsbG93IGFsbG9jYXRp b24gb2YgaHVnZSBwYWdlcyBmb3IKPiA+IGFyY2hpdGVjdHVyZXMgdGhhdCBoYWQgUE1EX09SREVS ID4gTUFYX09SREVSIGFuZCBub3QgdG8gYWxsb3cgdXNlciB0bwo+ID4gc2VsZWN0IHNpemUgb2Yg bWF4aW1hbCBwaHlzaWNhbGx5IGNvbnRpZ3VvdXMgYWxsb2NhdGlvbi4KPiA+Cj4gPiBDaGFuZ2Vz IHRvIE1BWF9PUkRFUiBmdW5kYW1lbnRhbGx5IGNoYW5nZSB0aGUgYmVoYXZpb3VyIG9mIGNvcmUg bW0gYW5kCj4gPiB1bmxlc3MgdXNlcnMgKnJlYWxseSoga25vdyB3aGF0IHRoZXkgYXJlIGRvaW5n IHRoZXJlIGlzIG5vIHJlYXNvbiB0byBjaG9vc2UKPiA+IG5vbi1kZWZhdWx0IHZhbHVlcyBzbyBo aWRpbmcgdGhpcyBvcHRpb24gYmVoaW5kIEVYUEVSVCBzZWVtcyB0b3RhbGx5Cj4gPiBhcHByb3By aWF0ZSB0byBtZS4KPiAKPiBJdCBzb3VuZHMgbmljZSBpbiB0aGVvcnkuIEluIHByYWN0aWNlLiBF WFBFUlQgaGlkZXMgdG9vIG11Y2guIFdoZW4geW91Cj4gZmxpcCBleHBlcnQsIHlvdSBleHBvc2Ug b3ZlciBhIDE3NWlzaCBuZXcgY29uZmlnIG9wdGlvbnMgd2hpY2ggYXJlCj4gaGlkZGVuIGJlaGlu ZCBFWFBFUlQuICBZb3UgZG9uJ3QgaGF2ZSB0byBrbm93IHdoYXQgeW91IGFyZSBkb2luZyBqdXN0 Cj4gd2l0aCB0aGUgTUFYX09SREVSLCBidXQgYSB3aG9sZSBidW5jaCBtb3JlIGFzIHdlbGwuICBJ ZiBldmVyeW9uZSB3ZXJlCj4gYWxyZWFkeSBydW5uaW5nIDEwLCB0aGlzIG1pZ2h0IGJlIGxlc3Mg b2YgYSBwcm9ibGVtLiBBdCBsZWFzdCBGZWRvcmEKPiBhbmQgUkhFTCBhcmUgcnVubmluZyAxMyBm b3IgNEsgcGFnZXMgb24gYWFyY2g2NC4gVGhpcyB3YXMgbm90IHNvbWUKPiBhY2NpZGVudGFsIGNo b2ljZSwgd2UgaGFkIHRvIGNhcnJ5IGEgcGF0Y2ggdG8gZXZlbiBhbGxvdyBpdCBmb3IgYQo+IHdo aWxlLiAgSWYgdGhpcyBkb2VzIGdvIGluIGFzIGlzLCB3ZSB3aWxsIGxpa2VseSBqdXN0IGNhcnJ5 IGEgcGF0Y2ggdG8KPiByZW1vdmUgdGhlICJpZiBFWFBFUlQiLCBidXQgdGhhdCBpcyBhIGJpdCBv ZiBhIGRpc3NlcnZpY2UgdG8gdXNlcnMgd2hvCj4gbWlnaHQgYmUgdHJ5aW5nIHRvIGRlYnVnIHNv bWV0aGluZyBlbHNlIHVwc3RyZWFtLCBiaXNlY3RpbmcgdXBzdHJlYW0KPiBrZXJuZWxzIG9yIHRl c3RpbmcgYSBwYXRjaC4gIEluIHRob3NlIGNhc2VzLCBwZW9wbGUgdGVuZCB0byB1c2UKPiBwcmlz dGluZSB1cHN0cmVhbSBzb3VyY2VzIHdpdGhvdXQgZGlzdHJvIHBhdGNoZXMgdG8gdmVyaWZ5LCBh bmQgdGhleQo+IHRlbmQgdG8gdXNlIHRoZWlyIGV4aXN0aW5nIGNvbmZpZ3MuIFdpdGggdGhpcyBj aGFuZ2UsIHRoZWlyIE1BWF9PUkRFUgo+IHdpbGwgZHJvcCB0byAxMCBmcm9tIDEzIHNpbGVudGx5 LiAgIFRoYXQgY2FuIGxvb2sgbGlrZSBhIGRpZmZlcmVudAo+IGlzc3VlIGVub3VnaCB0byBydWlu IGEgYmlzZWN0IG9yIGhhdmUgdGhlbSBnaXZlIGJhZCBmZWVkYmFjayBvbiBhCj4gcGF0Y2ggYmVj YXVzZSBpdCBpbnRyb2R1Y2VzIGEgInJlZ3Jlc3Npb24iIHdoaWNoIGlzIG5vdCBhIHJlZ3Jlc3Np b24KPiBhdCBhbGwsIGJ1dCBhIGNvbmZpZyBjaGFuZ2UgdGhleSBjb3VsZG4ndCBzZWUuCgpJZiB3 ZSByZW1vdmUgRVhQRVJUIChhcyBwcmlvciB0byB0aGlzIHBhdGNoKSwgSSdkIHJhdGhlciBrZWVw IHRoZSByYW5nZXMKYW5kIGF2b2lkIGhhdmluZyB0byBleHBsYWluIHRvIHBlb3BsZSB3aHkgc29t ZSByYW5kb20gTUFYX09SREVSIGRvZXNuJ3QKYnVpbGQgKGtlZXBpbmcgdGhlIHJhbmdlIHdvdWxk IGFsc28gbWFrZSBzZW5zZSBmb3IgcmFuZGNvbmZpZywgbm90IHN1cmUKd2UgZ290IHRvIGFueSBj b25jbHVzaW9uIHRoZXJlKS4KCi0tIApDYXRhbGluCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51 eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5v cmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==