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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B949C43460 for ; Tue, 6 Apr 2021 12:12:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3E513613C9 for ; Tue, 6 Apr 2021 12:12:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235662AbhDFMNG convert rfc822-to-8bit (ORCPT ); Tue, 6 Apr 2021 08:13:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:38052 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235680AbhDFMNF (ORCPT ); Tue, 6 Apr 2021 08:13:05 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0BC03613C2; Tue, 6 Apr 2021 12:12:58 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lTkZk-005qpW-3r; Tue, 06 Apr 2021 13:12:56 +0100 Date: Tue, 06 Apr 2021 13:12:55 +0100 Message-ID: <87lf9vpq60.wl-maz@kernel.org> From: Marc Zyngier To: Christophe Leroy Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, Thomas Bogendoerfer , Yoshinori Sato , Haojian Zhuang , Rich Felker , Thomas Gleixner , Robert Jarzmik , Daniel Mack Subject: Re: [PATCH 1/9] irqdomain: Reimplement irq_linear_revmap() with irq_find_mapping() In-Reply-To: <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu> References: <20210406093557.1073423-1-maz@kernel.org> <20210406093557.1073423-2-maz@kernel.org> <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: christophe.leroy@csgroup.eu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, tsbogend@alpha.franken.de, ysato@users.sourceforge.jp, haojian.zhuang@gmail.com, dalias@libc.org, tglx@linutronix.de, robert.jarzmik@free.fr, daniel@zonque.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org Christophe, On Tue, 06 Apr 2021 12:21:33 +0100, Christophe Leroy wrote: > > > > Le 06/04/2021 à 11:35, Marc Zyngier a écrit : > > irq_linear_revmap() is supposed to be a fast path for domain > > lookups, but it only exposes low-level details of the irqdomain > > implementation, details which are better kept private. > > Can you elaborate with more details ? Things like directly picking into the revmap are positively awful, and doesn't work if the domain has been constructed using the radix tree. Which on its own is totally broken, because things like irq_domain_create_hierarchy() will pick an implementation or the other. > > > > > The *overhead* between the two is only a function call and > > a couple of tests, so it is likely that noone can show any > > meaningful difference compared to the cost of taking an > > interrupt. > > Do you have any measurement ? I did measure things on arm64, and couldn't come up with any difference other than noise. > Can you make the "likely" a certitude ? Of course not. You can always come up with an artificial CPU implementation that has a very small exception entry overhead, and a ridiculously slow memory subsystem. Do I care about these? No. If you can come up with realistic platforms that show a regression with this patch, I'm all ears. > > > > > Reimplement irq_linear_revmap() with irq_find_mapping() > > in order to preserve source code compatibility, and > > rename the internal field for a measure. > > This is in complete contradiction with commit https://github.com/torvalds/linux/commit/d3dcb436 > > At that time, irq_linear_revmap() was less complex than what > irq_find_mapping() is today, and nevertheless it was considered worth > restoring in as a fast path. What has changed since then ? Over 8 years? Plenty. The use of irqdomains has been generalised, we have domain hierarchies, and if anything, this commit introduces the buggy behaviour I was mentioning above. I also don't see any mention of actual performance in that commit. And if we're worried about a fast path, being able to directly cache the irq_data in the revmap, hence skipping the irq_desc lookup that inevitable follows, is a much more interesting prospect than the "get useless data quick" that irq_linear_revmap() implements. This latter optimisation is what I am after. > Can you also explain the reason for the renaming of "linear_revmap" > into "revmap" ? What is that "measure" ? To catch the potential direct use of the reverse map field. Thanks, M. -- Without deviation from the norm, progress is not possible. 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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0B77C433ED for ; Tue, 6 Apr 2021 12:14:57 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 3B49D613BD for ; Tue, 6 Apr 2021 12:14:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B49D613BD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FF60b6XdFz3cFV for ; Tue, 6 Apr 2021 22:14:55 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=maz@kernel.org; receiver=) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (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 4FF5yN5mY8z3c0x for ; Tue, 6 Apr 2021 22:13:00 +1000 (AEST) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0BC03613C2; Tue, 6 Apr 2021 12:12:58 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lTkZk-005qpW-3r; Tue, 06 Apr 2021 13:12:56 +0100 Date: Tue, 06 Apr 2021 13:12:55 +0100 Message-ID: <87lf9vpq60.wl-maz@kernel.org> From: Marc Zyngier To: Christophe Leroy Subject: Re: [PATCH 1/9] irqdomain: Reimplement irq_linear_revmap() with irq_find_mapping() In-Reply-To: <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu> References: <20210406093557.1073423-1-maz@kernel.org> <20210406093557.1073423-2-maz@kernel.org> <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: christophe.leroy@csgroup.eu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, tsbogend@alpha.franken.de, ysato@users.sourceforge.jp, haojian.zhuang@gmail.com, dalias@libc.org, tglx@linutronix.de, robert.jarzmik@free.fr, daniel@zonque.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: Thomas Bogendoerfer , Yoshinori Sato , linux-sh@vger.kernel.org, Robert Jarzmik , linux-kernel@vger.kernel.org, Haojian Zhuang , linux-mips@vger.kernel.org, Rich Felker , Daniel Mack , Thomas Gleixner , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Christophe, On Tue, 06 Apr 2021 12:21:33 +0100, Christophe Leroy wrote: >=20 >=20 >=20 > Le 06/04/2021 =C3=A0 11:35, Marc Zyngier a =C3=A9crit=C2=A0: > > irq_linear_revmap() is supposed to be a fast path for domain > > lookups, but it only exposes low-level details of the irqdomain > > implementation, details which are better kept private. >=20 > Can you elaborate with more details ? Things like directly picking into the revmap are positively awful, and doesn't work if the domain has been constructed using the radix tree. Which on its own is totally broken, because things like irq_domain_create_hierarchy() will pick an implementation or the other. >=20 > >=20 > > The *overhead* between the two is only a function call and > > a couple of tests, so it is likely that noone can show any > > meaningful difference compared to the cost of taking an > > interrupt. >=20 > Do you have any measurement ? I did measure things on arm64, and couldn't come up with any difference other than noise. > Can you make the "likely" a certitude ? Of course not. You can always come up with an artificial CPU implementation that has a very small exception entry overhead, and a ridiculously slow memory subsystem. Do I care about these? No. If you can come up with realistic platforms that show a regression with this patch, I'm all ears. >=20 > >=20 > > Reimplement irq_linear_revmap() with irq_find_mapping() > > in order to preserve source code compatibility, and > > rename the internal field for a measure. >=20 > This is in complete contradiction with commit https://github.com/torvalds= /linux/commit/d3dcb436 >=20 > At that time, irq_linear_revmap() was less complex than what > irq_find_mapping() is today, and nevertheless it was considered worth > restoring in as a fast path. What has changed since then ? Over 8 years? Plenty. The use of irqdomains has been generalised, we have domain hierarchies, and if anything, this commit introduces the buggy behaviour I was mentioning above. I also don't see any mention of actual performance in that commit. And if we're worried about a fast path, being able to directly cache the irq_data in the revmap, hence skipping the irq_desc lookup that inevitable follows, is a much more interesting prospect than the "get useless data quick" that irq_linear_revmap() implements. This latter optimisation is what I am after. > Can you also explain the reason for the renaming of "linear_revmap" > into "revmap" ? What is that "measure" ? To catch the potential direct use of the reverse map field. Thanks, M. --=20 Without deviation from the norm, progress is not possible. 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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0034C433B4 for ; Tue, 6 Apr 2021 12:15:20 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 619E4613BD for ; Tue, 6 Apr 2021 12:15:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 619E4613BD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Subject:Cc:To: From:Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=OSuFxpvsnHTKVSPRuv1wPfTzxVtuAxEkCVSUJEakuhE=; b=kGELtOhqWVdEpPjGE+6kj+m5p IxlDFslakeBiznUU/KzN0nqYzQc9eIQ9gOygrBu2VjuWcAGJRbORWcDfkUIdqTrJhb1wjDctal40y yGnzy84OGnPSHD633q7itfuIbMwb1/QCNCbOHuc5o7rQfs79pykn1Y0AJ6x3y/661PrSH8o2XyugC x7xNTs87hawqpTFan+dNag5h3VEQUXScWfSmDKk+YU8yROUfY5lQW+BMgTQ5XcwcMxs1tPW0ToFls zIBh8to3qwzAYK4Ihy0QBhzSN4eDHJwI61dTmnGgxehLoJD46MhyNZwM9RL3+gSkt5f7uJDg7lXd/ I7zBEEZ4w==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lTkaQ-002XCd-HF; Tue, 06 Apr 2021 12:13:38 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lTkZo-002WyU-5N for linux-arm-kernel@lists.infradead.org; Tue, 06 Apr 2021 12:13:06 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0BC03613C2; Tue, 6 Apr 2021 12:12:58 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lTkZk-005qpW-3r; Tue, 06 Apr 2021 13:12:56 +0100 Date: Tue, 06 Apr 2021 13:12:55 +0100 Message-ID: <87lf9vpq60.wl-maz@kernel.org> From: Marc Zyngier To: Christophe Leroy Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, Thomas Bogendoerfer , Yoshinori Sato , Haojian Zhuang , Rich Felker , Thomas Gleixner , Robert Jarzmik , Daniel Mack Subject: Re: [PATCH 1/9] irqdomain: Reimplement irq_linear_revmap() with irq_find_mapping() In-Reply-To: <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu> References: <20210406093557.1073423-1-maz@kernel.org> <20210406093557.1073423-2-maz@kernel.org> <15be426f-4429-ebeb-1b4a-8342bce391e5@csgroup.eu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: christophe.leroy@csgroup.eu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-sh@vger.kernel.org, tsbogend@alpha.franken.de, ysato@users.sourceforge.jp, haojian.zhuang@gmail.com, dalias@libc.org, tglx@linutronix.de, robert.jarzmik@free.fr, daniel@zonque.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210406_131301_515545_12CBC88C X-CRM114-Status: GOOD ( 28.42 ) 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 Q2hyaXN0b3BoZSwKCk9uIFR1ZSwgMDYgQXByIDIwMjEgMTI6MjE6MzMgKzAxMDAsCkNocmlzdG9w aGUgTGVyb3kgPGNocmlzdG9waGUubGVyb3lAY3Nncm91cC5ldT4gd3JvdGU6Cj4gCj4gCj4gCj4g TGUgMDYvMDQvMjAyMSDDoCAxMTozNSwgTWFyYyBaeW5naWVyIGEgw6ljcml0wqA6Cj4gPiBpcnFf bGluZWFyX3Jldm1hcCgpIGlzIHN1cHBvc2VkIHRvIGJlIGEgZmFzdCBwYXRoIGZvciBkb21haW4K PiA+IGxvb2t1cHMsIGJ1dCBpdCBvbmx5IGV4cG9zZXMgbG93LWxldmVsIGRldGFpbHMgb2YgdGhl IGlycWRvbWFpbgo+ID4gaW1wbGVtZW50YXRpb24sIGRldGFpbHMgd2hpY2ggYXJlIGJldHRlciBr ZXB0IHByaXZhdGUuCj4gCj4gQ2FuIHlvdSBlbGFib3JhdGUgd2l0aCBtb3JlIGRldGFpbHMgPwoK VGhpbmdzIGxpa2UgZGlyZWN0bHkgcGlja2luZyBpbnRvIHRoZSByZXZtYXAgYXJlIHBvc2l0aXZl bHkgYXdmdWwsIGFuZApkb2Vzbid0IHdvcmsgaWYgdGhlIGRvbWFpbiBoYXMgYmVlbiBjb25zdHJ1 Y3RlZCB1c2luZyB0aGUgcmFkaXgKdHJlZS4gV2hpY2ggb24gaXRzIG93biBpcyB0b3RhbGx5IGJy b2tlbiwgYmVjYXVzZSB0aGluZ3MgbGlrZQppcnFfZG9tYWluX2NyZWF0ZV9oaWVyYXJjaHkoKSB3 aWxsIHBpY2sgYW4gaW1wbGVtZW50YXRpb24gb3IgdGhlCm90aGVyLgoKPiAKPiA+IAo+ID4gVGhl ICpvdmVyaGVhZCogYmV0d2VlbiB0aGUgdHdvIGlzIG9ubHkgYSBmdW5jdGlvbiBjYWxsIGFuZAo+ ID4gYSBjb3VwbGUgb2YgdGVzdHMsIHNvIGl0IGlzIGxpa2VseSB0aGF0IG5vb25lIGNhbiBzaG93 IGFueQo+ID4gbWVhbmluZ2Z1bCBkaWZmZXJlbmNlIGNvbXBhcmVkIHRvIHRoZSBjb3N0IG9mIHRh a2luZyBhbgo+ID4gaW50ZXJydXB0Lgo+IAo+IERvIHlvdSBoYXZlIGFueSBtZWFzdXJlbWVudCA/ CgpJIGRpZCBtZWFzdXJlIHRoaW5ncyBvbiBhcm02NCwgYW5kIGNvdWxkbid0IGNvbWUgdXAgd2l0 aCBhbnkKZGlmZmVyZW5jZSBvdGhlciB0aGFuIG5vaXNlLgoKPiBDYW4geW91IG1ha2UgdGhlICJs aWtlbHkiIGEgY2VydGl0dWRlID8KCk9mIGNvdXJzZSBub3QuIFlvdSBjYW4gYWx3YXlzIGNvbWUg dXAgd2l0aCBhbiBhcnRpZmljaWFsIENQVQppbXBsZW1lbnRhdGlvbiB0aGF0IGhhcyBhIHZlcnkg c21hbGwgZXhjZXB0aW9uIGVudHJ5IG92ZXJoZWFkLCBhbmQgYQpyaWRpY3Vsb3VzbHkgc2xvdyBt ZW1vcnkgc3Vic3lzdGVtLiBEbyBJIGNhcmUgYWJvdXQgdGhlc2U/IE5vLgoKSWYgeW91IGNhbiBj b21lIHVwIHdpdGggcmVhbGlzdGljIHBsYXRmb3JtcyB0aGF0IHNob3cgYSByZWdyZXNzaW9uCndp dGggdGhpcyBwYXRjaCwgSSdtIGFsbCBlYXJzLgoKPiAKPiA+IAo+ID4gUmVpbXBsZW1lbnQgaXJx X2xpbmVhcl9yZXZtYXAoKSB3aXRoIGlycV9maW5kX21hcHBpbmcoKQo+ID4gaW4gb3JkZXIgdG8g cHJlc2VydmUgc291cmNlIGNvZGUgY29tcGF0aWJpbGl0eSwgYW5kCj4gPiByZW5hbWUgdGhlIGlu dGVybmFsIGZpZWxkIGZvciBhIG1lYXN1cmUuCj4gCj4gVGhpcyBpcyBpbiBjb21wbGV0ZSBjb250 cmFkaWN0aW9uIHdpdGggY29tbWl0IGh0dHBzOi8vZ2l0aHViLmNvbS90b3J2YWxkcy9saW51eC9j b21taXQvZDNkY2I0MzYKPiAKPiBBdCB0aGF0IHRpbWUsIGlycV9saW5lYXJfcmV2bWFwKCkgd2Fz IGxlc3MgY29tcGxleCB0aGFuIHdoYXQKPiBpcnFfZmluZF9tYXBwaW5nKCkgaXMgdG9kYXksIGFu ZCBuZXZlcnRoZWxlc3MgaXQgd2FzIGNvbnNpZGVyZWQgd29ydGgKPiByZXN0b3JpbmcgaW4gYXMg YSBmYXN0IHBhdGguIFdoYXQgaGFzIGNoYW5nZWQgc2luY2UgdGhlbiA/CgpPdmVyIDggeWVhcnM/ IFBsZW50eS4gVGhlIHVzZSBvZiBpcnFkb21haW5zIGhhcyBiZWVuIGdlbmVyYWxpc2VkLCB3ZQpo YXZlIGRvbWFpbiBoaWVyYXJjaGllcywgYW5kIGlmIGFueXRoaW5nLCB0aGlzIGNvbW1pdCBpbnRy b2R1Y2VzIHRoZQpidWdneSBiZWhhdmlvdXIgSSB3YXMgbWVudGlvbmluZyBhYm92ZS4gSSBhbHNv IGRvbid0IHNlZSBhbnkgbWVudGlvbgpvZiBhY3R1YWwgcGVyZm9ybWFuY2UgaW4gdGhhdCBjb21t aXQuCgpBbmQgaWYgd2UncmUgd29ycmllZCBhYm91dCBhIGZhc3QgcGF0aCwgYmVpbmcgYWJsZSB0 byBkaXJlY3RseSBjYWNoZQp0aGUgaXJxX2RhdGEgaW4gdGhlIHJldm1hcCwgaGVuY2Ugc2tpcHBp bmcgdGhlIGlycV9kZXNjIGxvb2t1cCB0aGF0CmluZXZpdGFibGUgZm9sbG93cywgaXMgYSBtdWNo IG1vcmUgaW50ZXJlc3RpbmcgcHJvc3BlY3QgdGhhbiB0aGUgImdldAp1c2VsZXNzIGRhdGEgcXVp Y2siIHRoYXQgaXJxX2xpbmVhcl9yZXZtYXAoKSBpbXBsZW1lbnRzLgoKVGhpcyBsYXR0ZXIgb3B0 aW1pc2F0aW9uIGlzIHdoYXQgSSBhbSBhZnRlci4KCj4gQ2FuIHlvdSBhbHNvIGV4cGxhaW4gdGhl IHJlYXNvbiBmb3IgdGhlIHJlbmFtaW5nIG9mICJsaW5lYXJfcmV2bWFwIgo+IGludG8gInJldm1h cCIgPyBXaGF0IGlzIHRoYXQgIm1lYXN1cmUiID8KClRvIGNhdGNoIHRoZSBwb3RlbnRpYWwgZGly ZWN0IHVzZSBvZiB0aGUgcmV2ZXJzZSBtYXAgZmllbGQuCgpUaGFua3MsCgoJTS4KCi0tIApXaXRo b3V0IGRldmlhdGlvbiBmcm9tIHRoZSBub3JtLCBwcm9ncmVzcyBpcyBub3QgcG9zc2libGUuCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0t a2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcK aHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2Vy bmVsCg==