From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K.V" Date: Mon, 05 May 2014 15:52:26 +0000 Subject: Re: [PATCH] KVM: PPC: BOOK3S: HV: Don't try to allocate from kernel page allocator for hash page tab Message-Id: <87a9aw9qtx.fsf@linux.vnet.ibm.com> List-Id: References: <1399224322-22028-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <53677558.50900@suse.de> <87r4489ttk.fsf@linux.vnet.ibm.com> <20FFDF8F-1A3D-4719-B492-1E4B70F9D1B4@suse.de> In-Reply-To: <20FFDF8F-1A3D-4719-B492-1E4B70F9D1B4@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: "paulus@samba.org" , "linuxppc-dev@lists.ozlabs.org" , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" Alexander Graf writes: >> Am 05.05.2014 um 16:35 schrieb "Aneesh Kumar K.V" : >> >> Alexander Graf writes: >> >>>> On 05/04/2014 07:25 PM, Aneesh Kumar K.V wrote: >>>> We reserve 5% of total ram for CMA allocation and not using that can >>>> result in us running out of numa node memory with specific >>>> configuration. One caveat is we may not have node local hpt with pinned >>>> vcpu configuration. But currently libvirt also pins the vcpu to cpuset >>>> after creating hash page table. >>> >>> I don't understand the problem. Can you please elaborate? >> >> Lets take a system with 100GB RAM. We reserve around 5GB for htab >> allocation. Now if we use rest of available memory for hugetlbfs >> (because we want all the guest to be backed by huge pages), we would >> end up in a situation where we have a few GB of free RAM and 5GB of CMA >> reserve area. Now if we allow hash page table allocation to consume the >> free space, we would end up hitting page allocation failure for other >> non movable kernel allocation even though we still have 5GB CMA reserve >> space free. > > Isn't this a greater problem? We should start swapping before we hit > the point where non movable kernel allocation fails, no? But there is nothing much to swap. Because most of the memory is reserved for guest RAM via hugetlbfs. > > The fact that KVM uses a good number of normal kernel pages is maybe > suboptimal, but shouldn't be a critical problem. Yes. But then in this case we could do better isn't it ? We already have a large part of guest RAM kept aside for htab allocation which cannot be used for non movable allocation. And we ignore that reserve space and use other areas for hash page table allocation with the current code. We actually hit this case in one of the test box. KVM guest htab at c000001e50000000 (order 30), LPID 1 libvirtd invoked oom-killer: gfp_mask=0x2000d0, order=0,oom_score_adj=0 libvirtd cpuset=/ mems_allowed=0,16 CPU: 72 PID: 20044 Comm: libvirtd Not tainted 3.10.23-1401.pkvm2_1.4.ppc64 #1 Call Trace: [c000001e3b63f150] [c000000000017330] .show_stack+0x130/0x200(unreliable) [c000001e3b63f220] [c00000000087a888] .dump_stack+0x28/0x3c [c000001e3b63f290] [c000000000876a4c] .dump_header+0xbc/0x228 [c000001e3b63f360] [c0000000001dd838].oom_kill_process+0x318/0x4c0 [c000001e3b63f440] [c0000000001de258] .out_of_memory+0x518/0x550 [c000001e3b63f520] [c0000000001e5aac].__alloc_pages_nodemask+0xb3c/0xbf0 [c000001e3b63f700] [c000000000243580] .new_slab+0x440/0x490 [c000001e3b63f7a0] [c0000000008781fc] .__slab_alloc+0x17c/0x618 [c000001e3b63f8d0] [c0000000002467fc].kmem_cache_alloc_node_trace+0xcc/0x300 [c000001e3b63f990] [c00000000010f62c].alloc_fair_sched_group+0xfc/0x200 [c000001e3b63fa60] [c000000000104f00].sched_create_group+0x50/0xe0 [c000001e3b63fae0] [c000000000104fc0].cpu_cgroup_css_alloc+0x30/0x80 [c000001e3b63fb60] [c0000000001513ec] .cgroup_mkdir+0x2bc/0x6e0 [c000001e3b63fc50] [c000000000275aec] .vfs_mkdir+0x14c/0x220 [c000001e3b63fcf0] [c00000000027a734] .SyS_mkdirat+0x94/0x110 [c000001e3b63fdb0] [c00000000027a7e4] .SyS_mkdir+0x34/0x50 [c000001e3b63fe30] [c000000000009f54] syscall_exit+0x0/0x98 Node 0 DMA free:23424kB min:23424kB low:29248kB high:35136kB active_anon:0kB inactive_anon:128kB active_file:256kB inactive_file:384kB unevictable:9536kB isolated(anon):0kB isolated(file):0kB present:67108864kB managed:65931776kB mlocked:9536kB dirty:64kB writeback:0kB mapped:5376kB shmem:0kB slab_reclaimable:23616kB slab_unreclaimable:1237056kB kernel_stack:18256kB pagetables:1088kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:78 all_unreclaimable? yes lowmem_reserve[]: 0 0 0 Node 16 DMA free:5787008kB min:21376kB low:26688kB high:32064kB active_anon:1984kB inactive_anon:2112kB active_file:896kB inactive_file:64kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:67108864kB managed:60060032kB mlocked:0kB dirty:128kB writeback:3712kB mapped:0kB shmem:0kB slab_reclaimable:23424kB slab_unreclaimable:826048kB kernel_stack:576kB pagetables:1408kB unstable:0kB bounce:0kB free_cma:5767040kB writeback_tmp:0kB pages_scanned:756 all_unreclaimable? yes From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e28smtp03.in.ibm.com (e28smtp03.in.ibm.com [122.248.162.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 6F954140B04 for ; Tue, 6 May 2014 01:40:33 +1000 (EST) Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 5 May 2014 21:10:31 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp01.in.ibm.com (Postfix) with ESMTP id E03EBE004B for ; Mon, 5 May 2014 21:10:52 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s45FeZ9o65863920 for ; Mon, 5 May 2014 21:10:36 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s45FeR1I002645 for ; Mon, 5 May 2014 21:10:27 +0530 From: "Aneesh Kumar K.V" To: Alexander Graf Subject: Re: [PATCH] KVM: PPC: BOOK3S: HV: Don't try to allocate from kernel page allocator for hash page table. In-Reply-To: <20FFDF8F-1A3D-4719-B492-1E4B70F9D1B4@suse.de> References: <1399224322-22028-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <53677558.50900@suse.de> <87r4489ttk.fsf@linux.vnet.ibm.com> <20FFDF8F-1A3D-4719-B492-1E4B70F9D1B4@suse.de> Date: Mon, 05 May 2014 21:10:26 +0530 Message-ID: <87a9aw9qtx.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Cc: "paulus@samba.org" , "linuxppc-dev@lists.ozlabs.org" , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Alexander Graf writes: >> Am 05.05.2014 um 16:35 schrieb "Aneesh Kumar K.V" : >> >> Alexander Graf writes: >> >>>> On 05/04/2014 07:25 PM, Aneesh Kumar K.V wrote: >>>> We reserve 5% of total ram for CMA allocation and not using that can >>>> result in us running out of numa node memory with specific >>>> configuration. One caveat is we may not have node local hpt with pinned >>>> vcpu configuration. But currently libvirt also pins the vcpu to cpuset >>>> after creating hash page table. >>> >>> I don't understand the problem. Can you please elaborate? >> >> Lets take a system with 100GB RAM. We reserve around 5GB for htab >> allocation. Now if we use rest of available memory for hugetlbfs >> (because we want all the guest to be backed by huge pages), we would >> end up in a situation where we have a few GB of free RAM and 5GB of CMA >> reserve area. Now if we allow hash page table allocation to consume the >> free space, we would end up hitting page allocation failure for other >> non movable kernel allocation even though we still have 5GB CMA reserve >> space free. > > Isn't this a greater problem? We should start swapping before we hit > the point where non movable kernel allocation fails, no? But there is nothing much to swap. Because most of the memory is reserved for guest RAM via hugetlbfs. > > The fact that KVM uses a good number of normal kernel pages is maybe > suboptimal, but shouldn't be a critical problem. Yes. But then in this case we could do better isn't it ? We already have a large part of guest RAM kept aside for htab allocation which cannot be used for non movable allocation. And we ignore that reserve space and use other areas for hash page table allocation with the current code. We actually hit this case in one of the test box. KVM guest htab at c000001e50000000 (order 30), LPID 1 libvirtd invoked oom-killer: gfp_mask=0x2000d0, order=0,oom_score_adj=0 libvirtd cpuset=/ mems_allowed=0,16 CPU: 72 PID: 20044 Comm: libvirtd Not tainted 3.10.23-1401.pkvm2_1.4.ppc64 #1 Call Trace: [c000001e3b63f150] [c000000000017330] .show_stack+0x130/0x200(unreliable) [c000001e3b63f220] [c00000000087a888] .dump_stack+0x28/0x3c [c000001e3b63f290] [c000000000876a4c] .dump_header+0xbc/0x228 [c000001e3b63f360] [c0000000001dd838].oom_kill_process+0x318/0x4c0 [c000001e3b63f440] [c0000000001de258] .out_of_memory+0x518/0x550 [c000001e3b63f520] [c0000000001e5aac].__alloc_pages_nodemask+0xb3c/0xbf0 [c000001e3b63f700] [c000000000243580] .new_slab+0x440/0x490 [c000001e3b63f7a0] [c0000000008781fc] .__slab_alloc+0x17c/0x618 [c000001e3b63f8d0] [c0000000002467fc].kmem_cache_alloc_node_trace+0xcc/0x300 [c000001e3b63f990] [c00000000010f62c].alloc_fair_sched_group+0xfc/0x200 [c000001e3b63fa60] [c000000000104f00].sched_create_group+0x50/0xe0 [c000001e3b63fae0] [c000000000104fc0].cpu_cgroup_css_alloc+0x30/0x80 [c000001e3b63fb60] [c0000000001513ec] .cgroup_mkdir+0x2bc/0x6e0 [c000001e3b63fc50] [c000000000275aec] .vfs_mkdir+0x14c/0x220 [c000001e3b63fcf0] [c00000000027a734] .SyS_mkdirat+0x94/0x110 [c000001e3b63fdb0] [c00000000027a7e4] .SyS_mkdir+0x34/0x50 [c000001e3b63fe30] [c000000000009f54] syscall_exit+0x0/0x98 Node 0 DMA free:23424kB min:23424kB low:29248kB high:35136kB active_anon:0kB inactive_anon:128kB active_file:256kB inactive_file:384kB unevictable:9536kB isolated(anon):0kB isolated(file):0kB present:67108864kB managed:65931776kB mlocked:9536kB dirty:64kB writeback:0kB mapped:5376kB shmem:0kB slab_reclaimable:23616kB slab_unreclaimable:1237056kB kernel_stack:18256kB pagetables:1088kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:78 all_unreclaimable? yes lowmem_reserve[]: 0 0 0 Node 16 DMA free:5787008kB min:21376kB low:26688kB high:32064kB active_anon:1984kB inactive_anon:2112kB active_file:896kB inactive_file:64kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:67108864kB managed:60060032kB mlocked:0kB dirty:128kB writeback:3712kB mapped:0kB shmem:0kB slab_reclaimable:23424kB slab_unreclaimable:826048kB kernel_stack:576kB pagetables:1408kB unstable:0kB bounce:0kB free_cma:5767040kB writeback_tmp:0kB pages_scanned:756 all_unreclaimable? yes From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K.V" Subject: Re: [PATCH] KVM: PPC: BOOK3S: HV: Don't try to allocate from kernel page allocator for hash page table. Date: Mon, 05 May 2014 21:10:26 +0530 Message-ID: <87a9aw9qtx.fsf@linux.vnet.ibm.com> References: <1399224322-22028-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <53677558.50900@suse.de> <87r4489ttk.fsf@linux.vnet.ibm.com> <20FFDF8F-1A3D-4719-B492-1E4B70F9D1B4@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: "paulus@samba.org" , "linuxppc-dev@lists.ozlabs.org" , "kvm-ppc@vger.kernel.org" , "kvm@vger.kernel.org" To: Alexander Graf Return-path: In-Reply-To: <20FFDF8F-1A3D-4719-B492-1E4B70F9D1B4@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppd-linuxppc64-dev=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" List-Id: kvm.vger.kernel.org QWxleGFuZGVyIEdyYWYgPGFncmFmQHN1c2UuZGU+IHdyaXRlczoKCj4+IEFtIDA1LjA1LjIwMTQg dW0gMTY6MzUgc2NocmllYiAiQW5lZXNoIEt1bWFyIEsuViIgPGFuZWVzaC5rdW1hckBsaW51eC52 bmV0LmlibS5jb20+Ogo+PiAKPj4gQWxleGFuZGVyIEdyYWYgPGFncmFmQHN1c2UuZGU+IHdyaXRl czoKPj4gCj4+Pj4gT24gMDUvMDQvMjAxNCAwNzoyNSBQTSwgQW5lZXNoIEt1bWFyIEsuViB3cm90 ZToKPj4+PiBXZSByZXNlcnZlIDUlIG9mIHRvdGFsIHJhbSBmb3IgQ01BIGFsbG9jYXRpb24gYW5k IG5vdCB1c2luZyB0aGF0IGNhbgo+Pj4+IHJlc3VsdCBpbiB1cyBydW5uaW5nIG91dCBvZiBudW1h IG5vZGUgbWVtb3J5IHdpdGggc3BlY2lmaWMKPj4+PiBjb25maWd1cmF0aW9uLiBPbmUgY2F2ZWF0 IGlzIHdlIG1heSBub3QgaGF2ZSBub2RlIGxvY2FsIGhwdCB3aXRoIHBpbm5lZAo+Pj4+IHZjcHUg Y29uZmlndXJhdGlvbi4gQnV0IGN1cnJlbnRseSBsaWJ2aXJ0IGFsc28gcGlucyB0aGUgdmNwdSB0 byBjcHVzZXQKPj4+PiBhZnRlciBjcmVhdGluZyBoYXNoIHBhZ2UgdGFibGUuCj4+PiAKPj4+IEkg ZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbS4gQ2FuIHlvdSBwbGVhc2UgZWxhYm9yYXRlPwo+ PiAKPj4gTGV0cyB0YWtlIGEgc3lzdGVtIHdpdGggMTAwR0IgUkFNLiBXZSByZXNlcnZlIGFyb3Vu ZCA1R0IgZm9yIGh0YWIKPj4gYWxsb2NhdGlvbi4gTm93IGlmIHdlIHVzZSByZXN0IG9mIGF2YWls YWJsZSBtZW1vcnkgZm9yIGh1Z2V0bGJmcwo+PiAoYmVjYXVzZSB3ZSB3YW50IGFsbCB0aGUgZ3Vl c3QgdG8gYmUgYmFja2VkIGJ5IGh1Z2UgcGFnZXMpLCB3ZSB3b3VsZAo+PiBlbmQgdXAgaW4gYSBz aXR1YXRpb24gd2hlcmUgd2UgaGF2ZSBhIGZldyBHQiBvZiBmcmVlIFJBTSBhbmQgNUdCIG9mIENN QQo+PiByZXNlcnZlIGFyZWEuIE5vdyBpZiB3ZSBhbGxvdyBoYXNoIHBhZ2UgdGFibGUgYWxsb2Nh dGlvbiB0byBjb25zdW1lIHRoZQo+PiBmcmVlIHNwYWNlLCB3ZSB3b3VsZCBlbmQgdXAgaGl0dGlu ZyBwYWdlIGFsbG9jYXRpb24gZmFpbHVyZSBmb3Igb3RoZXIKPj4gbm9uIG1vdmFibGUga2VybmVs IGFsbG9jYXRpb24gZXZlbiB0aG91Z2ggd2Ugc3RpbGwgaGF2ZSA1R0IgQ01BIHJlc2VydmUKPj4g c3BhY2UgZnJlZS4KPgo+IElzbid0IHRoaXMgYSBncmVhdGVyIHByb2JsZW0/IFdlIHNob3VsZCBz dGFydCBzd2FwcGluZyBiZWZvcmUgd2UgaGl0Cj4gdGhlIHBvaW50IHdoZXJlIG5vbiBtb3ZhYmxl IGtlcm5lbCBhbGxvY2F0aW9uIGZhaWxzLCBubz8KCkJ1dCB0aGVyZSBpcyBub3RoaW5nIG11Y2gg dG8gc3dhcC4gQmVjYXVzZSBtb3N0IG9mIHRoZSBtZW1vcnkgaXMKcmVzZXJ2ZWQgZm9yIGd1ZXN0 IFJBTSB2aWEgaHVnZXRsYmZzLiAKCj4KPiBUaGUgZmFjdCB0aGF0IEtWTSB1c2VzIGEgZ29vZCBu dW1iZXIgb2Ygbm9ybWFsIGtlcm5lbCBwYWdlcyBpcyBtYXliZQo+IHN1Ym9wdGltYWwsIGJ1dCBz aG91bGRuJ3QgYmUgYSBjcml0aWNhbCBwcm9ibGVtLgoKWWVzLiBCdXQgdGhlbiBpbiB0aGlzIGNh c2Ugd2UgY291bGQgZG8gYmV0dGVyIGlzbid0IGl0ID8gV2UgYWxyZWFkeSBoYXZlCmEgbGFyZ2Ug cGFydCBvZiBndWVzdCBSQU0ga2VwdCBhc2lkZSBmb3IgaHRhYiBhbGxvY2F0aW9uIHdoaWNoIGNh bm5vdCBiZQp1c2VkIGZvciBub24gbW92YWJsZSBhbGxvY2F0aW9uLiBBbmQgd2UgaWdub3JlIHRo YXQgcmVzZXJ2ZSBzcGFjZSBhbmQKdXNlIG90aGVyIGFyZWFzIGZvciBoYXNoIHBhZ2UgdGFibGUg YWxsb2NhdGlvbiB3aXRoIHRoZSBjdXJyZW50IGNvZGUuCgpXZSBhY3R1YWxseSBoaXQgdGhpcyBj YXNlIGluIG9uZSBvZiB0aGUgdGVzdCBib3guCgogS1ZNIGd1ZXN0IGh0YWIgYXQgYzAwMDAwMWU1 MDAwMDAwMCAob3JkZXIgMzApLCBMUElEIDEKIGxpYnZpcnRkIGludm9rZWQgb29tLWtpbGxlcjog Z2ZwX21hc2s9MHgyMDAwZDAsIG9yZGVyPTAsb29tX3Njb3JlX2Fkaj0wCiBsaWJ2aXJ0ZCBjcHVz ZXQ9LyBtZW1zX2FsbG93ZWQ9MCwxNgogQ1BVOiA3MiBQSUQ6IDIwMDQ0IENvbW06IGxpYnZpcnRk IE5vdCB0YWludGVkIDMuMTAuMjMtMTQwMS5wa3ZtMl8xLjQucHBjNjQgIzEKIENhbGwgVHJhY2U6 CiBbYzAwMDAwMWUzYjYzZjE1MF0gW2MwMDAwMDAwMDAwMTczMzBdIC5zaG93X3N0YWNrKzB4MTMw LzB4MjAwKHVucmVsaWFibGUpCiBbYzAwMDAwMWUzYjYzZjIyMF0gW2MwMDAwMDAwMDA4N2E4ODhd IC5kdW1wX3N0YWNrKzB4MjgvMHgzYwogW2MwMDAwMDFlM2I2M2YyOTBdIFtjMDAwMDAwMDAwODc2 YTRjXSAuZHVtcF9oZWFkZXIrMHhiYy8weDIyOAogW2MwMDAwMDFlM2I2M2YzNjBdIFtjMDAwMDAw MDAwMWRkODM4XS5vb21fa2lsbF9wcm9jZXNzKzB4MzE4LzB4NGMwCiBbYzAwMDAwMWUzYjYzZjQ0 MF0gW2MwMDAwMDAwMDAxZGUyNThdIC5vdXRfb2ZfbWVtb3J5KzB4NTE4LzB4NTUwCiBbYzAwMDAw MWUzYjYzZjUyMF0gW2MwMDAwMDAwMDAxZTVhYWNdLl9fYWxsb2NfcGFnZXNfbm9kZW1hc2srMHhi M2MvMHhiZjAKIFtjMDAwMDAxZTNiNjNmNzAwXSBbYzAwMDAwMDAwMDI0MzU4MF0gLm5ld19zbGFi KzB4NDQwLzB4NDkwCiBbYzAwMDAwMWUzYjYzZjdhMF0gW2MwMDAwMDAwMDA4NzgxZmNdIC5fX3Ns YWJfYWxsb2MrMHgxN2MvMHg2MTgKIFtjMDAwMDAxZTNiNjNmOGQwXSBbYzAwMDAwMDAwMDI0Njdm Y10ua21lbV9jYWNoZV9hbGxvY19ub2RlX3RyYWNlKzB4Y2MvMHgzMDAKIFtjMDAwMDAxZTNiNjNm OTkwXSBbYzAwMDAwMDAwMDEwZjYyY10uYWxsb2NfZmFpcl9zY2hlZF9ncm91cCsweGZjLzB4MjAw CiBbYzAwMDAwMWUzYjYzZmE2MF0gW2MwMDAwMDAwMDAxMDRmMDBdLnNjaGVkX2NyZWF0ZV9ncm91 cCsweDUwLzB4ZTAKIFtjMDAwMDAxZTNiNjNmYWUwXSBbYzAwMDAwMDAwMDEwNGZjMF0uY3B1X2Nn cm91cF9jc3NfYWxsb2MrMHgzMC8weDgwCiBbYzAwMDAwMWUzYjYzZmI2MF0gW2MwMDAwMDAwMDAx NTEzZWNdIC5jZ3JvdXBfbWtkaXIrMHgyYmMvMHg2ZTAKIFtjMDAwMDAxZTNiNjNmYzUwXSBbYzAw MDAwMDAwMDI3NWFlY10gLnZmc19ta2RpcisweDE0Yy8weDIyMAogW2MwMDAwMDFlM2I2M2ZjZjBd IFtjMDAwMDAwMDAwMjdhNzM0XSAuU3lTX21rZGlyYXQrMHg5NC8weDExMAogW2MwMDAwMDFlM2I2 M2ZkYjBdIFtjMDAwMDAwMDAwMjdhN2U0XSAuU3lTX21rZGlyKzB4MzQvMHg1MAogW2MwMDAwMDFl M2I2M2ZlMzBdIFtjMDAwMDAwMDAwMDA5ZjU0XSBzeXNjYWxsX2V4aXQrMHgwLzB4OTgKCgpOb2Rl IDAgRE1BIGZyZWU6MjM0MjRrQiBtaW46MjM0MjRrQiBsb3c6MjkyNDhrQiBoaWdoOjM1MTM2a0IK YWN0aXZlX2Fub246MGtCIGluYWN0aXZlX2Fub246MTI4a0IgYWN0aXZlX2ZpbGU6MjU2a0IgaW5h Y3RpdmVfZmlsZTozODRrQgp1bmV2aWN0YWJsZTo5NTM2a0IgaXNvbGF0ZWQoYW5vbik6MGtCIGlz b2xhdGVkKGZpbGUpOjBrQiBwcmVzZW50OjY3MTA4ODY0a0IKbWFuYWdlZDo2NTkzMTc3NmtCIG1s b2NrZWQ6OTUzNmtCIGRpcnR5OjY0a0Igd3JpdGViYWNrOjBrQiBtYXBwZWQ6NTM3NmtCCnNobWVt OjBrQiBzbGFiX3JlY2xhaW1hYmxlOjIzNjE2a0Igc2xhYl91bnJlY2xhaW1hYmxlOjEyMzcwNTZr QgprZXJuZWxfc3RhY2s6MTgyNTZrQiBwYWdldGFibGVzOjEwODhrQiB1bnN0YWJsZTowa0IgYm91 bmNlOjBrQiBmcmVlX2NtYTowa0IKd3JpdGViYWNrX3RtcDowa0IgcGFnZXNfc2Nhbm5lZDo3OCBh bGxfdW5yZWNsYWltYWJsZT8geWVzCmxvd21lbV9yZXNlcnZlW106IDAgMCAwCk5vZGUgMTYgRE1B IGZyZWU6NTc4NzAwOGtCIG1pbjoyMTM3NmtCIGxvdzoyNjY4OGtCIGhpZ2g6MzIwNjRrQgphY3Rp dmVfYW5vbjoxOTg0a0IgaW5hY3RpdmVfYW5vbjoyMTEya0IgYWN0aXZlX2ZpbGU6ODk2a0IgaW5h Y3RpdmVfZmlsZTo2NGtCCnVuZXZpY3RhYmxlOjBrQiBpc29sYXRlZChhbm9uKTowa0IgaXNvbGF0 ZWQoZmlsZSk6MGtCIHByZXNlbnQ6NjcxMDg4NjRrQgptYW5hZ2VkOjYwMDYwMDMya0IgbWxvY2tl ZDowa0IgZGlydHk6MTI4a0Igd3JpdGViYWNrOjM3MTJrQiBtYXBwZWQ6MGtCCnNobWVtOjBrQiBz bGFiX3JlY2xhaW1hYmxlOjIzNDI0a0Igc2xhYl91bnJlY2xhaW1hYmxlOjgyNjA0OGtCCmtlcm5l bF9zdGFjazo1NzZrQiBwYWdldGFibGVzOjE0MDhrQiB1bnN0YWJsZTowa0IgYm91bmNlOjBrQiBm cmVlX2NtYTo1NzY3MDQwa0IKd3JpdGViYWNrX3RtcDowa0IgcGFnZXNfc2Nhbm5lZDo3NTYgYWxs X3VucmVjbGFpbWFibGU/IHllcwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KTGludXhwcGMtZGV2IG1haWxpbmcgbGlzdApMaW51eHBwYy1kZXZAbGlzdHMu b3psYWJzLm9yZwpodHRwczovL2xpc3RzLm96bGFicy5vcmcvbGlzdGluZm8vbGludXhwcGMtZGV2