From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935250Ab2JXQhc (ORCPT ); Wed, 24 Oct 2012 12:37:32 -0400 Received: from service87.mimecast.com ([91.220.42.44]:46966 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935193Ab2JXQha convert rfc822-to-8bit (ORCPT ); Wed, 24 Oct 2012 12:37:30 -0400 Message-ID: <1351096647.23327.64.camel@hornet> Subject: Re: [RFC] Energy/power monitoring within the kernel From: Pawel Moll To: Guenter Roeck Cc: Amit Daniel Kachhap , Zhang Rui , Viresh Kumar , Daniel Lezcano , Jean Delvare , Steven Rostedt , Frederic Weisbecker , Ingo Molnar , Jesper Juhl , Thomas Renninger , Jean Pihet , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "lm-sensors@lm-sensors.org" , "linaro-dev@lists.linaro.org" Date: Wed, 24 Oct 2012 17:37:27 +0100 In-Reply-To: <20121023220240.GA25895@roeck-us.net> References: <1351013449.9070.5.camel@hornet> <20121023220240.GA25895@roeck-us.net> X-Mailer: Evolution 3.6.0-0ubuntu3 Mime-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2012 16:37:28.0261 (UTC) FILETIME=[DB032750:01CDB205] X-MC-Unique: 112102417372802201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote: > > Traditionally such data should be exposed to the user via hwmon sysfs > > interface, and that's exactly what I did for "my" platform - I have > > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good > > enough to draw pretty graphs in userspace. Everyone was happy... > > > Only driver supporting "energy" output so far is ibmaem, and the reported energy > is supposed to be cumulative, as in energy = power * time. Do you mean power, > possibly ? So the vexpress would be the second one, than :-) as the energy "monitor" actually on the latest tiles reports 64-bit value of microJoules consumed (or produced) since the power-up. Some of the older boards were able to report instant power, but this metrics is less useful in our case. > > Now I am getting new requests to do more with this data. In particular > > I'm asked how to add such information to ftrace/perf output. The second > > most frequent request is about providing it to a "energy aware" > > cpufreq governor. > > Anything energy related would have to be along the line of "do something after a > certain amount of work has been performed", which at least at the surface does > not make much sense to me, unless you mean something along the line of a > process scheduler which schedules a process not based on time slices but based > on energy consumed, ie if you want to define a time slice not in milli-seconds > but in Joule. Actually there is some research being done in this direction, but it's way too early to draw any conclusions... > If so, I would argue that a similar behavior could be achieved by varying the > duration of time slices with the current CPU speed, or simply by using cycle > count instead of time as time slice parameter. Not that I am sure if such an > approach would really be of interest for anyone. > > Or do you really mean power, not energy, such as in "reduce CPU speed if its > power consumption is above X Watt" ? Uh. To be completely honest I must answer: I'm not sure how the "energy aware" cpufreq governor is supposed to work. I have been simply asked to provide the data in some standard way, if possible. > I am not sure how this would be expected to work. hwmon is, by its very nature, > a passive subsystem: It doesn't do anything unless data is explicitly requested > from it. It does not update an attribute unless that attribute is read. > That does not seem to fit well with the idea of tracing - which assumes > that some activity is happening, ultimately, all by itself, presumably > periodically. The idea to have a user space application read hwmon data only > for it to trigger trace events does not seem to be very compelling to me. What I had in mind was similar to what adt7470 driver does. The driver would automatically access the device every now and then to update it's internal state and generate the trace event on the way. This auto-refresh "feature" is particularly appealing for me, as on some of "my" platforms can take up to 500 microseconds to actually get the data. So doing this in background (and providing users with the last known value in the meantime) seems attractive. > An exception is if a monitoring device suppports interrupts, and if its driver > actually implements those interrupts. This is, however, not the case for most of > the current drivers (if any), mostly because interrupt support for hardware > monitoring devices is very platform dependent and thus difficult to implement. Interestingly enough the newest version of our platform control micro (doing the energy monitoring as well) can generate and interrupt when a transaction is finished, so I was planning to periodically update the all sort of values. And again, generating a trace event on this opportunity would be trivial. > > Of course a particular driver could register its own perf PMU on its > > own. It's certainly an option, just very suboptimal in my opinion. > > Or maybe not? Maybe the task is so specialized that it makes sense? > > > We had a couple of attempts to provide an in-kernel API. Unfortunately, > the result was, at least so far, more complexity on the driver side. > So the difficulty is really to define an API which is really simple, and does > not just complicate driver development for a (presumably) rare use case. Yes, I appreciate this. That's why this option is actually my least favourite. Anyway, what I was thinking about was just a thin shin that *can* be used by a driver to register some particular value with the core (so it can be enumerated and accessed by in-kernel clients) and the core could (or not) create a sysfs attribute for this value on behalf of the driver. Seems lightweight enough, unless previous experience suggests otherwise? Cheers! Paweł From mboxrd@z Thu Jan 1 00:00:00 1970 From: pawel.moll@arm.com (Pawel Moll) Date: Wed, 24 Oct 2012 17:37:27 +0100 Subject: [RFC] Energy/power monitoring within the kernel In-Reply-To: <20121023220240.GA25895@roeck-us.net> References: <1351013449.9070.5.camel@hornet> <20121023220240.GA25895@roeck-us.net> Message-ID: <1351096647.23327.64.camel@hornet> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote: > > Traditionally such data should be exposed to the user via hwmon sysfs > > interface, and that's exactly what I did for "my" platform - I have > > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good > > enough to draw pretty graphs in userspace. Everyone was happy... > > > Only driver supporting "energy" output so far is ibmaem, and the reported energy > is supposed to be cumulative, as in energy = power * time. Do you mean power, > possibly ? So the vexpress would be the second one, than :-) as the energy "monitor" actually on the latest tiles reports 64-bit value of microJoules consumed (or produced) since the power-up. Some of the older boards were able to report instant power, but this metrics is less useful in our case. > > Now I am getting new requests to do more with this data. In particular > > I'm asked how to add such information to ftrace/perf output. The second > > most frequent request is about providing it to a "energy aware" > > cpufreq governor. > > Anything energy related would have to be along the line of "do something after a > certain amount of work has been performed", which at least at the surface does > not make much sense to me, unless you mean something along the line of a > process scheduler which schedules a process not based on time slices but based > on energy consumed, ie if you want to define a time slice not in milli-seconds > but in Joule. Actually there is some research being done in this direction, but it's way too early to draw any conclusions... > If so, I would argue that a similar behavior could be achieved by varying the > duration of time slices with the current CPU speed, or simply by using cycle > count instead of time as time slice parameter. Not that I am sure if such an > approach would really be of interest for anyone. > > Or do you really mean power, not energy, such as in "reduce CPU speed if its > power consumption is above X Watt" ? Uh. To be completely honest I must answer: I'm not sure how the "energy aware" cpufreq governor is supposed to work. I have been simply asked to provide the data in some standard way, if possible. > I am not sure how this would be expected to work. hwmon is, by its very nature, > a passive subsystem: It doesn't do anything unless data is explicitly requested > from it. It does not update an attribute unless that attribute is read. > That does not seem to fit well with the idea of tracing - which assumes > that some activity is happening, ultimately, all by itself, presumably > periodically. The idea to have a user space application read hwmon data only > for it to trigger trace events does not seem to be very compelling to me. What I had in mind was similar to what adt7470 driver does. The driver would automatically access the device every now and then to update it's internal state and generate the trace event on the way. This auto-refresh "feature" is particularly appealing for me, as on some of "my" platforms can take up to 500 microseconds to actually get the data. So doing this in background (and providing users with the last known value in the meantime) seems attractive. > An exception is if a monitoring device suppports interrupts, and if its driver > actually implements those interrupts. This is, however, not the case for most of > the current drivers (if any), mostly because interrupt support for hardware > monitoring devices is very platform dependent and thus difficult to implement. Interestingly enough the newest version of our platform control micro (doing the energy monitoring as well) can generate and interrupt when a transaction is finished, so I was planning to periodically update the all sort of values. And again, generating a trace event on this opportunity would be trivial. > > Of course a particular driver could register its own perf PMU on its > > own. It's certainly an option, just very suboptimal in my opinion. > > Or maybe not? Maybe the task is so specialized that it makes sense? > > > We had a couple of attempts to provide an in-kernel API. Unfortunately, > the result was, at least so far, more complexity on the driver side. > So the difficulty is really to define an API which is really simple, and does > not just complicate driver development for a (presumably) rare use case. Yes, I appreciate this. That's why this option is actually my least favourite. Anyway, what I was thinking about was just a thin shin that *can* be used by a driver to register some particular value with the core (so it can be enumerated and accessed by in-kernel clients) and the core could (or not) create a sysfs attribute for this value on behalf of the driver. Seems lightweight enough, unless previous experience suggests otherwise? Cheers! Pawe? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pawel Moll Date: Wed, 24 Oct 2012 16:37:27 +0000 Subject: Re: [lm-sensors] [RFC] Energy/power monitoring within the kernel Message-Id: <1351096647.23327.64.camel@hornet> List-Id: References: <1351013449.9070.5.camel@hornet> <20121023220240.GA25895@roeck-us.net> In-Reply-To: <20121023220240.GA25895@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Guenter Roeck Cc: Amit Daniel Kachhap , Zhang Rui , Viresh Kumar , Daniel Lezcano , Jean Delvare , Steven Rostedt , Frederic Weisbecker , Ingo Molnar , Jesper Juhl , Thomas Renninger , Jean Pihet , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "lm-sensors@lm-sensors.org" , "linaro-dev@lists.linaro.org" T24gVHVlLCAyMDEyLTEwLTIzIGF0IDIzOjAyICswMTAwLCBHdWVudGVyIFJvZWNrIHdyb3RlOgo+ ID4gVHJhZGl0aW9uYWxseSBzdWNoIGRhdGEgc2hvdWxkIGJlIGV4cG9zZWQgdG8gdGhlIHVzZXIg dmlhIGh3bW9uIHN5c2ZzCj4gPiBpbnRlcmZhY2UsIGFuZCB0aGF0J3MgZXhhY3RseSB3aGF0IEkg ZGlkIGZvciAibXkiIHBsYXRmb3JtIC0gSSBoYXZlCj4gPiBhIC9zeXMvY2xhc3MvaHdtb24vaHdt b24qL2RldmljZS9lbmVyZ3kqX2lucHV0IGFuZCB0aGlzIHdhcyBnb29kCj4gPiBlbm91Z2ggdG8g ZHJhdyBwcmV0dHkgZ3JhcGhzIGluIHVzZXJzcGFjZS4gRXZlcnlvbmUgd2FzIGhhcHB5Li4uCj4g PiAKPiBPbmx5IGRyaXZlciBzdXBwb3J0aW5nICJlbmVyZ3kiIG91dHB1dCBzbyBmYXIgaXMgaWJt YWVtLCBhbmQgdGhlIHJlcG9ydGVkIGVuZXJneQo+IGlzIHN1cHBvc2VkIHRvIGJlIGN1bXVsYXRp dmUsIGFzIGluIGVuZXJneSA9IHBvd2VyICogdGltZS4gRG8geW91IG1lYW4gcG93ZXIsCj4gcG9z c2libHkgPwoKU28gdGhlIHZleHByZXNzIHdvdWxkIGJlIHRoZSBzZWNvbmQgb25lLCB0aGFuIDot KSBhcyB0aGUgZW5lcmd5CiJtb25pdG9yIiBhY3R1YWxseSBvbiB0aGUgbGF0ZXN0IHRpbGVzIHJl cG9ydHMgNjQtYml0IHZhbHVlIG9mCm1pY3JvSm91bGVzIGNvbnN1bWVkIChvciBwcm9kdWNlZCkg c2luY2UgdGhlIHBvd2VyLXVwLgoKU29tZSBvZiB0aGUgb2xkZXIgYm9hcmRzIHdlcmUgYWJsZSB0 byByZXBvcnQgaW5zdGFudCBwb3dlciwgYnV0IHRoaXMKbWV0cmljcyBpcyBsZXNzIHVzZWZ1bCBp biBvdXIgY2FzZS4KCj4gPiBOb3cgSSBhbSBnZXR0aW5nIG5ldyByZXF1ZXN0cyB0byBkbyBtb3Jl IHdpdGggdGhpcyBkYXRhLiBJbiBwYXJ0aWN1bGFyCj4gPiBJJ20gYXNrZWQgaG93IHRvIGFkZCBz dWNoIGluZm9ybWF0aW9uIHRvIGZ0cmFjZS9wZXJmIG91dHB1dC4gVGhlIHNlY29uZAo+ID4gbW9z dCBmcmVxdWVudCByZXF1ZXN0IGlzIGFib3V0IHByb3ZpZGluZyBpdCB0byBhICJlbmVyZ3kgYXdh cmUiCj4gPiBjcHVmcmVxIGdvdmVybm9yLgo+IAo+IEFueXRoaW5nIGVuZXJneSByZWxhdGVkIHdv dWxkIGhhdmUgdG8gYmUgYWxvbmcgdGhlIGxpbmUgb2YgImRvIHNvbWV0aGluZyBhZnRlciBhCj4g Y2VydGFpbiBhbW91bnQgb2Ygd29yayBoYXMgYmVlbiBwZXJmb3JtZWQiLCB3aGljaCBhdCBsZWFz dCBhdCB0aGUgc3VyZmFjZSBkb2VzCj4gbm90IG1ha2UgbXVjaCBzZW5zZSB0byBtZSwgdW5sZXNz IHlvdSBtZWFuIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZSBvZiBhCj4gcHJvY2VzcyBzY2hlZHVs ZXIgd2hpY2ggc2NoZWR1bGVzIGEgcHJvY2VzcyBub3QgYmFzZWQgb24gdGltZSBzbGljZXMgYnV0 IGJhc2VkCj4gb24gZW5lcmd5IGNvbnN1bWVkLCBpZSBpZiB5b3Ugd2FudCB0byBkZWZpbmUgYSB0 aW1lIHNsaWNlIG5vdCBpbiBtaWxsaS1zZWNvbmRzCj4gYnV0IGluIEpvdWxlLgoKQWN0dWFsbHkg dGhlcmUgaXMgc29tZSByZXNlYXJjaCBiZWluZyBkb25lIGluIHRoaXMgZGlyZWN0aW9uLCBidXQg aXQncwp3YXkgdG9vIGVhcmx5IHRvIGRyYXcgYW55IGNvbmNsdXNpb25zLi4uCgo+IElmIHNvLCBJ IHdvdWxkIGFyZ3VlIHRoYXQgYSBzaW1pbGFyIGJlaGF2aW9yIGNvdWxkIGJlIGFjaGlldmVkIGJ5 IHZhcnlpbmcgdGhlCj4gZHVyYXRpb24gb2YgdGltZSBzbGljZXMgd2l0aCB0aGUgY3VycmVudCBD UFUgc3BlZWQsIG9yIHNpbXBseSBieSB1c2luZyBjeWNsZQo+IGNvdW50IGluc3RlYWQgb2YgdGlt ZSBhcyB0aW1lIHNsaWNlIHBhcmFtZXRlci4gTm90IHRoYXQgSSBhbSBzdXJlIGlmIHN1Y2ggYW4K PiBhcHByb2FjaCB3b3VsZCByZWFsbHkgYmUgb2YgaW50ZXJlc3QgZm9yIGFueW9uZS4gCj4gCj4g T3IgZG8geW91IHJlYWxseSBtZWFuIHBvd2VyLCBub3QgZW5lcmd5LCBzdWNoIGFzIGluICJyZWR1 Y2UgQ1BVIHNwZWVkIGlmIGl0cwo+IHBvd2VyIGNvbnN1bXB0aW9uIGlzIGFib3ZlIFggV2F0dCIg PwoKVWguIFRvIGJlIGNvbXBsZXRlbHkgaG9uZXN0IEkgbXVzdCBhbnN3ZXI6IEknbSBub3Qgc3Vy ZSBob3cgdGhlICJlbmVyZ3kKYXdhcmUiIGNwdWZyZXEgZ292ZXJub3IgaXMgc3VwcG9zZWQgdG8g d29yay4gSSBoYXZlIGJlZW4gc2ltcGx5IGFza2VkIHRvCnByb3ZpZGUgdGhlIGRhdGEgaW4gc29t ZSBzdGFuZGFyZCB3YXksIGlmIHBvc3NpYmxlLgoKPiBJIGFtIG5vdCBzdXJlIGhvdyB0aGlzIHdv dWxkIGJlIGV4cGVjdGVkIHRvIHdvcmsuIGh3bW9uIGlzLCBieSBpdHMgdmVyeSBuYXR1cmUsCj4g YSBwYXNzaXZlIHN1YnN5c3RlbTogSXQgZG9lc24ndCBkbyBhbnl0aGluZyB1bmxlc3MgZGF0YSBp cyBleHBsaWNpdGx5IHJlcXVlc3RlZAo+IGZyb20gaXQuIEl0IGRvZXMgbm90IHVwZGF0ZSBhbiBh dHRyaWJ1dGUgdW5sZXNzIHRoYXQgYXR0cmlidXRlIGlzIHJlYWQuCj4gVGhhdCBkb2VzIG5vdCBz ZWVtIHRvIGZpdCB3ZWxsIHdpdGggdGhlIGlkZWEgb2YgdHJhY2luZyAtIHdoaWNoIGFzc3VtZXMK PiB0aGF0IHNvbWUgYWN0aXZpdHkgaXMgaGFwcGVuaW5nLCB1bHRpbWF0ZWx5LCBhbGwgYnkgaXRz ZWxmLCBwcmVzdW1hYmx5Cj4gcGVyaW9kaWNhbGx5LiBUaGUgaWRlYSB0byBoYXZlIGEgdXNlciBz cGFjZSBhcHBsaWNhdGlvbiByZWFkIGh3bW9uIGRhdGEgb25seQo+IGZvciBpdCB0byB0cmlnZ2Vy IHRyYWNlIGV2ZW50cyBkb2VzIG5vdCBzZWVtIHRvIGJlIHZlcnkgY29tcGVsbGluZyB0byBtZS4K CldoYXQgSSBoYWQgaW4gbWluZCB3YXMgc2ltaWxhciB0byB3aGF0IGFkdDc0NzAgZHJpdmVyIGRv ZXMuIFRoZSBkcml2ZXIKd291bGQgYXV0b21hdGljYWxseSBhY2Nlc3MgdGhlIGRldmljZSBldmVy eSBub3cgYW5kIHRoZW4gdG8gdXBkYXRlIGl0J3MKaW50ZXJuYWwgc3RhdGUgYW5kIGdlbmVyYXRl IHRoZSB0cmFjZSBldmVudCBvbiB0aGUgd2F5LiBUaGlzCmF1dG8tcmVmcmVzaCAiZmVhdHVyZSIg aXMgcGFydGljdWxhcmx5IGFwcGVhbGluZyBmb3IgbWUsIGFzIG9uIHNvbWUgb2YKIm15IiBwbGF0 Zm9ybXMgY2FuIHRha2UgdXAgdG8gNTAwIG1pY3Jvc2Vjb25kcyB0byBhY3R1YWxseSBnZXQgdGhl IGRhdGEuClNvIGRvaW5nIHRoaXMgaW4gYmFja2dyb3VuZCAoYW5kIHByb3ZpZGluZyB1c2VycyB3 aXRoIHRoZSBsYXN0IGtub3duCnZhbHVlIGluIHRoZSBtZWFudGltZSkgc2VlbXMgYXR0cmFjdGl2 ZS4KCj4gQW4gZXhjZXB0aW9uIGlzIGlmIGEgbW9uaXRvcmluZyBkZXZpY2Ugc3VwcHBvcnRzIGlu dGVycnVwdHMsIGFuZCBpZiBpdHMgZHJpdmVyCj4gYWN0dWFsbHkgaW1wbGVtZW50cyB0aG9zZSBp bnRlcnJ1cHRzLiBUaGlzIGlzLCBob3dldmVyLCBub3QgdGhlIGNhc2UgZm9yIG1vc3Qgb2YKPiB0 aGUgY3VycmVudCBkcml2ZXJzIChpZiBhbnkpLCBtb3N0bHkgYmVjYXVzZSBpbnRlcnJ1cHQgc3Vw cG9ydCBmb3IgaGFyZHdhcmUKPiBtb25pdG9yaW5nIGRldmljZXMgaXMgdmVyeSBwbGF0Zm9ybSBk ZXBlbmRlbnQgYW5kIHRodXMgZGlmZmljdWx0IHRvIGltcGxlbWVudC4KCkludGVyZXN0aW5nbHkg ZW5vdWdoIHRoZSBuZXdlc3QgdmVyc2lvbiBvZiBvdXIgcGxhdGZvcm0gY29udHJvbCBtaWNybwoo ZG9pbmcgdGhlIGVuZXJneSBtb25pdG9yaW5nIGFzIHdlbGwpIGNhbiBnZW5lcmF0ZSBhbmQgaW50 ZXJydXB0IHdoZW4gYQp0cmFuc2FjdGlvbiBpcyBmaW5pc2hlZCwgc28gSSB3YXMgcGxhbm5pbmcg dG8gcGVyaW9kaWNhbGx5IHVwZGF0ZSB0aGUKYWxsIHNvcnQgb2YgdmFsdWVzLiBBbmQgYWdhaW4s IGdlbmVyYXRpbmcgYSB0cmFjZSBldmVudCBvbiB0aGlzCm9wcG9ydHVuaXR5IHdvdWxkIGJlIHRy aXZpYWwuCgo+ID4gT2YgY291cnNlIGEgcGFydGljdWxhciBkcml2ZXIgY291bGQgcmVnaXN0ZXIg aXRzIG93biBwZXJmIFBNVSBvbiBpdHMKPiA+IG93bi4gSXQncyBjZXJ0YWlubHkgYW4gb3B0aW9u LCBqdXN0IHZlcnkgc3Vib3B0aW1hbCBpbiBteSBvcGluaW9uLgo+ID4gT3IgbWF5YmUgbm90PyBN YXliZSB0aGUgdGFzayBpcyBzbyBzcGVjaWFsaXplZCB0aGF0IGl0IG1ha2VzIHNlbnNlPwo+ID4g Cj4gV2UgaGFkIGEgY291cGxlIG9mIGF0dGVtcHRzIHRvIHByb3ZpZGUgYW4gaW4ta2VybmVsIEFQ SS4gVW5mb3J0dW5hdGVseSwKPiB0aGUgcmVzdWx0IHdhcywgYXQgbGVhc3Qgc28gZmFyLCBtb3Jl IGNvbXBsZXhpdHkgb24gdGhlIGRyaXZlciBzaWRlLgo+IFNvIHRoZSBkaWZmaWN1bHR5IGlzIHJl YWxseSB0byBkZWZpbmUgYW4gQVBJIHdoaWNoIGlzIHJlYWxseSBzaW1wbGUsIGFuZCBkb2VzCj4g bm90IGp1c3QgY29tcGxpY2F0ZSBkcml2ZXIgZGV2ZWxvcG1lbnQgZm9yIGEgKHByZXN1bWFibHkp IHJhcmUgdXNlIGNhc2UuCgpZZXMsIEkgYXBwcmVjaWF0ZSB0aGlzLiBUaGF0J3Mgd2h5IHRoaXMg b3B0aW9uIGlzIGFjdHVhbGx5IG15IGxlYXN0CmZhdm91cml0ZS4gQW55d2F5LCB3aGF0IEkgd2Fz IHRoaW5raW5nIGFib3V0IHdhcyBqdXN0IGEgdGhpbiBzaGluIHRoYXQKKmNhbiogYmUgdXNlZCBi eSBhIGRyaXZlciB0byByZWdpc3RlciBzb21lIHBhcnRpY3VsYXIgdmFsdWUgd2l0aCB0aGUKY29y ZSAoc28gaXQgY2FuIGJlIGVudW1lcmF0ZWQgYW5kIGFjY2Vzc2VkIGJ5IGluLWtlcm5lbCBjbGll bnRzKSBhbmQgdGhlCmNvcmUgY291bGQgKG9yIG5vdCkgY3JlYXRlIGEgc3lzZnMgYXR0cmlidXRl IGZvciB0aGlzIHZhbHVlIG9uIGJlaGFsZiBvZgp0aGUgZHJpdmVyLiBTZWVtcyBsaWdodHdlaWdo dCBlbm91Z2gsIHVubGVzcyBwcmV2aW91cyBleHBlcmllbmNlCnN1Z2dlc3RzIG90aGVyd2lzZT8K CkNoZWVycyEKClBhd2XFggoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMu b3JnCmh0dHA6Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNv cnM