From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933085AbcFPA0N (ORCPT ); Wed, 15 Jun 2016 20:26:13 -0400 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:33254 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752739AbcFPA0K (ORCPT ); Wed, 15 Jun 2016 20:26:10 -0400 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.150 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Thu, 16 Jun 2016 09:26:17 +0900 From: Minchan Kim To: Anshuman Khandual CC: Andrew Morton , , , Rik van Riel , Vlastimil Babka , Joonsoo Kim , Mel Gorman , Hugh Dickins , Rafael Aquini , , Jonathan Corbet , John Einar Reitan , , Sergey Senozhatsky , Gioh Kim Subject: Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration Message-ID: <20160616002617.GM17127@bbox> References: <1463754225-31311-1-git-send-email-minchan@kernel.org> <1463754225-31311-3-git-send-email-minchan@kernel.org> <20160530013926.GB8683@bbox> <20160531000117.GB18314@bbox> <575E7F0B.8010201@linux.vnet.ibm.com> <20160615023249.GG17127@bbox> <5760F970.7060805@linux.vnet.ibm.com> MIME-Version: 1.0 In-Reply-To: <5760F970.7060805@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB01/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/16 09:26:06, Serialize by Router on LGEKRMHUB01/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/16 09:26:06, Serialize complete at 2016/06/16 09:26:06 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: > On 06/15/2016 08:02 AM, Minchan Kim wrote: > > Hi, > > > > On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote: > >> > On 05/31/2016 05:31 AM, Minchan Kim wrote: > >>> > > @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, struct page *newpage, > >>> > > int rc = -EAGAIN; > >>> > > int page_was_mapped = 0; > >>> > > struct anon_vma *anon_vma = NULL; > >>> > > + bool is_lru = !__PageMovable(page); > >>> > > > >>> > > if (!trylock_page(page)) { > >>> > > if (!force || mode == MIGRATE_ASYNC) > >>> > > @@ -871,6 +1002,11 @@ static int __unmap_and_move(struct page *page, struct page *newpage, > >>> > > goto out_unlock_both; > >>> > > } > >>> > > > >>> > > + if (unlikely(!is_lru)) { > >>> > > + rc = move_to_new_page(newpage, page, mode); > >>> > > + goto out_unlock_both; > >>> > > + } > >>> > > + > >> > > >> > Hello Minchan, > >> > > >> > I might be missing something here but does this implementation support the > >> > scenario where these non LRU pages owned by the driver mapped as PTE into > >> > process page table ? Because the "goto out_unlock_both" statement above > >> > skips all the PTE unmap, putting a migration PTE and removing the migration > >> > PTE steps. > > You're right. Unfortunately, it doesn't support right now but surely, > > it's my TODO after landing this work. > > > > Could you share your usecase? > > Sure. Thanks a lot! > > My driver has privately managed non LRU pages which gets mapped into user space > process page table through f_ops->mmap() and vmops->fault() which then updates > the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing Hmm, page_add_file_rmap is not exported function. How does your driver can use it? Do you use vm_insert_pfn? What type your vma is? VM_PFNMMAP or VM_MIXEDMAP? I want to make dummy driver to simulate your case. It would be very helpful to implement/test pte-mapped non-lru page migration feature. That's why I ask now. > to note here is that the page->mapping eventually points to struct address_space > (file->f_mapping) which belongs to the character device file (created using mknod) > which we are using for establishing the mmap() regions in the user space. > > Now as per this new framework, all the page's are to be made __SetPageMovable before > passing the list down to migrate_pages(). Now __SetPageMovable() takes *new* struct > address_space as an argument and replaces the existing page->mapping. Now thats the > problem, we have lost all our connection to the existing file RMAP information. This We could change __SetPageMovable doesn't need mapping argument. Instead, it just marks PAGE_MAPPING_MOVABLE into page->mapping. For that, user should take care of setting page->mapping earlier than marking the flag. > stands as a problem when we try to migrate these non LRU pages which are PTE mapped. > The rmap_walk_file() never finds them in the VMA, skips all the migrate PTE steps and > then the migration eventually fails. > > Seems like assigning a new struct address_space to the page through __SetPageMovable() > is the source of the problem. Can it take the existing (file->f_mapping) as an argument We can set existing file->f_mapping under the page_lock. > in there ? Sure, but then can we override file system generic ->isolate(), ->putback(), I don't get it. Why does it override file system generic functions? > ->migratepages() functions ? I dont think so. I am sure, there must be some work around > to fix this problem for the driver. But we need to rethink this framework from supporting > these mapped non LRU pages point of view. > > I might be missing something here, feel free to point out. > > - Anshuman > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f70.google.com (mail-pa0-f70.google.com [209.85.220.70]) by kanga.kvack.org (Postfix) with ESMTP id CDA586B0005 for ; Wed, 15 Jun 2016 20:26:10 -0400 (EDT) Received: by mail-pa0-f70.google.com with SMTP id fg1so59625771pad.1 for ; Wed, 15 Jun 2016 17:26:10 -0700 (PDT) Received: from lgeamrelo13.lge.com (LGEAMRELO13.lge.com. [156.147.23.53]) by mx.google.com with ESMTP id l7si14375717pac.212.2016.06.15.17.26.09 for ; Wed, 15 Jun 2016 17:26:09 -0700 (PDT) Date: Thu, 16 Jun 2016 09:26:17 +0900 From: Minchan Kim Subject: Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration Message-ID: <20160616002617.GM17127@bbox> References: <1463754225-31311-1-git-send-email-minchan@kernel.org> <1463754225-31311-3-git-send-email-minchan@kernel.org> <20160530013926.GB8683@bbox> <20160531000117.GB18314@bbox> <575E7F0B.8010201@linux.vnet.ibm.com> <20160615023249.GG17127@bbox> <5760F970.7060805@linux.vnet.ibm.com> MIME-Version: 1.0 In-Reply-To: <5760F970.7060805@linux.vnet.ibm.com> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: owner-linux-mm@kvack.org List-ID: To: Anshuman Khandual Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Rik van Riel , Vlastimil Babka , Joonsoo Kim , Mel Gorman , Hugh Dickins , Rafael Aquini , virtualization@lists.linux-foundation.org, Jonathan Corbet , John Einar Reitan , dri-devel@lists.freedesktop.org, Sergey Senozhatsky , Gioh Kim On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote: > On 06/15/2016 08:02 AM, Minchan Kim wrote: > > Hi, > > > > On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote: > >> > On 05/31/2016 05:31 AM, Minchan Kim wrote: > >>> > > @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, struct page *newpage, > >>> > > int rc = -EAGAIN; > >>> > > int page_was_mapped = 0; > >>> > > struct anon_vma *anon_vma = NULL; > >>> > > + bool is_lru = !__PageMovable(page); > >>> > > > >>> > > if (!trylock_page(page)) { > >>> > > if (!force || mode == MIGRATE_ASYNC) > >>> > > @@ -871,6 +1002,11 @@ static int __unmap_and_move(struct page *page, struct page *newpage, > >>> > > goto out_unlock_both; > >>> > > } > >>> > > > >>> > > + if (unlikely(!is_lru)) { > >>> > > + rc = move_to_new_page(newpage, page, mode); > >>> > > + goto out_unlock_both; > >>> > > + } > >>> > > + > >> > > >> > Hello Minchan, > >> > > >> > I might be missing something here but does this implementation support the > >> > scenario where these non LRU pages owned by the driver mapped as PTE into > >> > process page table ? Because the "goto out_unlock_both" statement above > >> > skips all the PTE unmap, putting a migration PTE and removing the migration > >> > PTE steps. > > You're right. Unfortunately, it doesn't support right now but surely, > > it's my TODO after landing this work. > > > > Could you share your usecase? > > Sure. Thanks a lot! > > My driver has privately managed non LRU pages which gets mapped into user space > process page table through f_ops->mmap() and vmops->fault() which then updates > the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). One thing Hmm, page_add_file_rmap is not exported function. How does your driver can use it? Do you use vm_insert_pfn? What type your vma is? VM_PFNMMAP or VM_MIXEDMAP? I want to make dummy driver to simulate your case. It would be very helpful to implement/test pte-mapped non-lru page migration feature. That's why I ask now. > to note here is that the page->mapping eventually points to struct address_space > (file->f_mapping) which belongs to the character device file (created using mknod) > which we are using for establishing the mmap() regions in the user space. > > Now as per this new framework, all the page's are to be made __SetPageMovable before > passing the list down to migrate_pages(). Now __SetPageMovable() takes *new* struct > address_space as an argument and replaces the existing page->mapping. Now thats the > problem, we have lost all our connection to the existing file RMAP information. This We could change __SetPageMovable doesn't need mapping argument. Instead, it just marks PAGE_MAPPING_MOVABLE into page->mapping. For that, user should take care of setting page->mapping earlier than marking the flag. > stands as a problem when we try to migrate these non LRU pages which are PTE mapped. > The rmap_walk_file() never finds them in the VMA, skips all the migrate PTE steps and > then the migration eventually fails. > > Seems like assigning a new struct address_space to the page through __SetPageMovable() > is the source of the problem. Can it take the existing (file->f_mapping) as an argument We can set existing file->f_mapping under the page_lock. > in there ? Sure, but then can we override file system generic ->isolate(), ->putback(), I don't get it. Why does it override file system generic functions? > ->migratepages() functions ? I dont think so. I am sure, there must be some work around > to fix this problem for the driver. But we need to rethink this framework from supporting > these mapped non LRU pages point of view. > > I might be missing something here, feel free to point out. > > - Anshuman > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Minchan Kim Subject: Re: [PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration Date: Thu, 16 Jun 2016 09:26:17 +0900 Message-ID: <20160616002617.GM17127@bbox> References: <1463754225-31311-1-git-send-email-minchan@kernel.org> <1463754225-31311-3-git-send-email-minchan@kernel.org> <20160530013926.GB8683@bbox> <20160531000117.GB18314@bbox> <575E7F0B.8010201@linux.vnet.ibm.com> <20160615023249.GG17127@bbox> <5760F970.7060805@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from lgeamrelo13.lge.com (LGEAMRELO13.lge.com [156.147.23.53]) by gabe.freedesktop.org (Postfix) with ESMTP id 729CE6E1FC for ; Thu, 16 Jun 2016 00:26:09 +0000 (UTC) In-Reply-To: <5760F970.7060805@linux.vnet.ibm.com> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Anshuman Khandual Cc: Rik van Riel , Sergey Senozhatsky , Rafael Aquini , Jonathan Corbet , Hugh Dickins , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, virtualization@lists.linux-foundation.org, John Einar Reitan , linux-mm@kvack.org, Gioh Kim , Mel Gorman , Andrew Morton , Joonsoo Kim , Vlastimil Babka List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBKdW4gMTUsIDIwMTYgYXQgMTI6MTU6MDRQTSArMDUzMCwgQW5zaHVtYW4gS2hhbmR1 YWwgd3JvdGU6Cj4gT24gMDYvMTUvMjAxNiAwODowMiBBTSwgTWluY2hhbiBLaW0gd3JvdGU6Cj4g PiBIaSwKPiA+IAo+ID4gT24gTW9uLCBKdW4gMTMsIDIwMTYgYXQgMDM6MDg6MTlQTSArMDUzMCwg QW5zaHVtYW4gS2hhbmR1YWwgd3JvdGU6Cj4gPj4gPiBPbiAwNS8zMS8yMDE2IDA1OjMxIEFNLCBN aW5jaGFuIEtpbSB3cm90ZToKPiA+Pj4gPiA+IEBAIC03OTEsNiArOTIxLDcgQEAgc3RhdGljIGlu dCBfX3VubWFwX2FuZF9tb3ZlKHN0cnVjdCBwYWdlICpwYWdlLCBzdHJ1Y3QgcGFnZSAqbmV3cGFn ZSwKPiA+Pj4gPiA+ICAJaW50IHJjID0gLUVBR0FJTjsKPiA+Pj4gPiA+ICAJaW50IHBhZ2Vfd2Fz X21hcHBlZCA9IDA7Cj4gPj4+ID4gPiAgCXN0cnVjdCBhbm9uX3ZtYSAqYW5vbl92bWEgPSBOVUxM Owo+ID4+PiA+ID4gKwlib29sIGlzX2xydSA9ICFfX1BhZ2VNb3ZhYmxlKHBhZ2UpOwo+ID4+PiA+ ID4gIAo+ID4+PiA+ID4gIAlpZiAoIXRyeWxvY2tfcGFnZShwYWdlKSkgewo+ID4+PiA+ID4gIAkJ aWYgKCFmb3JjZSB8fCBtb2RlID09IE1JR1JBVEVfQVNZTkMpCj4gPj4+ID4gPiBAQCAtODcxLDYg KzEwMDIsMTEgQEAgc3RhdGljIGludCBfX3VubWFwX2FuZF9tb3ZlKHN0cnVjdCBwYWdlICpwYWdl LCBzdHJ1Y3QgcGFnZSAqbmV3cGFnZSwKPiA+Pj4gPiA+ICAJCWdvdG8gb3V0X3VubG9ja19ib3Ro Owo+ID4+PiA+ID4gIAl9Cj4gPj4+ID4gPiAgCj4gPj4+ID4gPiArCWlmICh1bmxpa2VseSghaXNf bHJ1KSkgewo+ID4+PiA+ID4gKwkJcmMgPSBtb3ZlX3RvX25ld19wYWdlKG5ld3BhZ2UsIHBhZ2Us IG1vZGUpOwo+ID4+PiA+ID4gKwkJZ290byBvdXRfdW5sb2NrX2JvdGg7Cj4gPj4+ID4gPiArCX0K PiA+Pj4gPiA+ICsKPiA+PiA+IAo+ID4+ID4gSGVsbG8gTWluY2hhbiwKPiA+PiA+IAo+ID4+ID4g SSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlIGJ1dCBkb2VzIHRoaXMgaW1wbGVtZW50 YXRpb24gc3VwcG9ydCB0aGUKPiA+PiA+IHNjZW5hcmlvIHdoZXJlIHRoZXNlIG5vbiBMUlUgcGFn ZXMgb3duZWQgYnkgdGhlIGRyaXZlciBtYXBwZWQgYXMgUFRFIGludG8KPiA+PiA+IHByb2Nlc3Mg cGFnZSB0YWJsZSA/IEJlY2F1c2UgdGhlICJnb3RvIG91dF91bmxvY2tfYm90aCIgc3RhdGVtZW50 IGFib3ZlCj4gPj4gPiBza2lwcyBhbGwgdGhlIFBURSB1bm1hcCwgcHV0dGluZyBhIG1pZ3JhdGlv biBQVEUgYW5kIHJlbW92aW5nIHRoZSBtaWdyYXRpb24KPiA+PiA+IFBURSBzdGVwcy4KPiA+IFlv dSdyZSByaWdodC4gVW5mb3J0dW5hdGVseSwgaXQgZG9lc24ndCBzdXBwb3J0IHJpZ2h0IG5vdyBi dXQgc3VyZWx5LAo+ID4gaXQncyBteSBUT0RPIGFmdGVyIGxhbmRpbmcgdGhpcyB3b3JrLgo+ID4g Cj4gPiBDb3VsZCB5b3Ugc2hhcmUgeW91ciB1c2VjYXNlPwo+IAo+IFN1cmUuCgpUaGFua3MgYSBs b3QhCgo+IAo+IE15IGRyaXZlciBoYXMgcHJpdmF0ZWx5IG1hbmFnZWQgbm9uIExSVSBwYWdlcyB3 aGljaCBnZXRzIG1hcHBlZCBpbnRvIHVzZXIgc3BhY2UKPiBwcm9jZXNzIHBhZ2UgdGFibGUgdGhy b3VnaCBmX29wcy0+bW1hcCgpIGFuZCB2bW9wcy0+ZmF1bHQoKSB3aGljaCB0aGVuIHVwZGF0ZXMK PiB0aGUgZmlsZSBSTUFQIChwYWdlLT5tYXBwaW5nLT5pX21tYXApIHRocm91Z2ggcGFnZV9hZGRf ZmlsZV9ybWFwKHBhZ2UpLiBPbmUgdGhpbmcKCkhtbSwgcGFnZV9hZGRfZmlsZV9ybWFwIGlzIG5v dCBleHBvcnRlZCBmdW5jdGlvbi4gSG93IGRvZXMgeW91ciBkcml2ZXIgY2FuIHVzZSBpdD8KRG8g eW91IHVzZSB2bV9pbnNlcnRfcGZuPwpXaGF0IHR5cGUgeW91ciB2bWEgaXM/IFZNX1BGTk1NQVAg b3IgVk1fTUlYRURNQVA/CgpJIHdhbnQgdG8gbWFrZSBkdW1teSBkcml2ZXIgdG8gc2ltdWxhdGUg eW91ciBjYXNlLgpJdCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgdG8gaW1wbGVtZW50L3Rlc3QgcHRl LW1hcHBlZCBub24tbHJ1IHBhZ2UKbWlncmF0aW9uIGZlYXR1cmUuIFRoYXQncyB3aHkgSSBhc2sg bm93LgoKPiB0byBub3RlIGhlcmUgaXMgdGhhdCB0aGUgcGFnZS0+bWFwcGluZyBldmVudHVhbGx5 IHBvaW50cyB0byBzdHJ1Y3QgYWRkcmVzc19zcGFjZQo+IChmaWxlLT5mX21hcHBpbmcpIHdoaWNo IGJlbG9uZ3MgdG8gdGhlIGNoYXJhY3RlciBkZXZpY2UgZmlsZSAoY3JlYXRlZCB1c2luZyBta25v ZCkKPiB3aGljaCB3ZSBhcmUgdXNpbmcgZm9yIGVzdGFibGlzaGluZyB0aGUgbW1hcCgpIHJlZ2lv bnMgaW4gdGhlIHVzZXIgc3BhY2UuCj4gCj4gTm93IGFzIHBlciB0aGlzIG5ldyBmcmFtZXdvcmss IGFsbCB0aGUgcGFnZSdzIGFyZSB0byBiZSBtYWRlIF9fU2V0UGFnZU1vdmFibGUgYmVmb3JlCj4g cGFzc2luZyB0aGUgbGlzdCBkb3duIHRvIG1pZ3JhdGVfcGFnZXMoKS4gTm93IF9fU2V0UGFnZU1v dmFibGUoKSB0YWtlcyAqbmV3KiBzdHJ1Y3QKPiBhZGRyZXNzX3NwYWNlIGFzIGFuIGFyZ3VtZW50 IGFuZCByZXBsYWNlcyB0aGUgZXhpc3RpbmcgcGFnZS0+bWFwcGluZy4gTm93IHRoYXRzIHRoZQo+ IHByb2JsZW0sIHdlIGhhdmUgbG9zdCBhbGwgb3VyIGNvbm5lY3Rpb24gdG8gdGhlIGV4aXN0aW5n IGZpbGUgUk1BUCBpbmZvcm1hdGlvbi4gVGhpcwoKV2UgY291bGQgY2hhbmdlIF9fU2V0UGFnZU1v dmFibGUgZG9lc24ndCBuZWVkIG1hcHBpbmcgYXJndW1lbnQuCkluc3RlYWQsIGl0IGp1c3QgbWFy a3MgUEFHRV9NQVBQSU5HX01PVkFCTEUgaW50byBwYWdlLT5tYXBwaW5nLgpGb3IgdGhhdCwgdXNl ciBzaG91bGQgdGFrZSBjYXJlIG9mIHNldHRpbmcgcGFnZS0+bWFwcGluZyBlYXJsaWVyIHRoYW4K bWFya2luZyB0aGUgZmxhZy4KCj4gc3RhbmRzIGFzIGEgcHJvYmxlbSB3aGVuIHdlIHRyeSB0byBt aWdyYXRlIHRoZXNlIG5vbiBMUlUgcGFnZXMgd2hpY2ggYXJlIFBURSBtYXBwZWQuCj4gVGhlIHJt YXBfd2Fsa19maWxlKCkgbmV2ZXIgZmluZHMgdGhlbSBpbiB0aGUgVk1BLCBza2lwcyBhbGwgdGhl IG1pZ3JhdGUgUFRFIHN0ZXBzIGFuZAo+IHRoZW4gdGhlIG1pZ3JhdGlvbiBldmVudHVhbGx5IGZh aWxzLgo+IAo+IFNlZW1zIGxpa2UgYXNzaWduaW5nIGEgbmV3IHN0cnVjdCBhZGRyZXNzX3NwYWNl IHRvIHRoZSBwYWdlIHRocm91Z2ggX19TZXRQYWdlTW92YWJsZSgpCj4gaXMgdGhlIHNvdXJjZSBv ZiB0aGUgcHJvYmxlbS4gQ2FuIGl0IHRha2UgdGhlIGV4aXN0aW5nIChmaWxlLT5mX21hcHBpbmcp IGFzIGFuIGFyZ3VtZW50CldlIGNhbiBzZXQgZXhpc3RpbmcgZmlsZS0+Zl9tYXBwaW5nIHVuZGVy IHRoZSBwYWdlX2xvY2suCgo+IGluIHRoZXJlID8gU3VyZSwgYnV0IHRoZW4gY2FuIHdlIG92ZXJy aWRlIGZpbGUgc3lzdGVtIGdlbmVyaWMgLT5pc29sYXRlKCksIC0+cHV0YmFjaygpLAoKSSBkb24n dCBnZXQgaXQuIFdoeSBkb2VzIGl0IG92ZXJyaWRlIGZpbGUgc3lzdGVtIGdlbmVyaWMgZnVuY3Rp b25zPwoKPiAtPm1pZ3JhdGVwYWdlcygpIGZ1bmN0aW9ucyA/IEkgZG9udCB0aGluayBzby4gSSBh bSBzdXJlLCB0aGVyZSBtdXN0IGJlIHNvbWUgd29yayBhcm91bmQKPiB0byBmaXggdGhpcyBwcm9i bGVtIGZvciB0aGUgZHJpdmVyLiBCdXQgd2UgbmVlZCB0byByZXRoaW5rIHRoaXMgZnJhbWV3b3Jr IGZyb20gc3VwcG9ydGluZwo+IHRoZXNlIG1hcHBlZCBub24gTFJVIHBhZ2VzIHBvaW50IG9mIHZp ZXcuCj4gCj4gSSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlLCBmZWVsIGZyZWUgdG8g cG9pbnQgb3V0Lgo+IAo+IC0gQW5zaHVtYW4KPiAKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlz dHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4v bGlzdGluZm8vZHJpLWRldmVsCg==