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 F1920C07CA9 for ; Tue, 28 Nov 2023 10:16:05 +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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mZ/anxiI8Z24AUmbBbfPDOPEfCQjs/3lka7RSYN56PA=; b=4Cud1yjKD7sCO4 NyXRrWtPf4xaGwTWAIJRPsjZJ/xs5KFe/BvkHDSGvSSBI6bcZWk+9xAHAJBCYXt++rY37osV2vVpe 4PEpl/lQde70NaoIsgrvu+Xy4ph3QIWmw4Ne05rm2OdgIxKMYOYVhkEbXMl1f3mKrIev5ZWbDmyRz GBV+GSTJUJ4IOROadmz4BaW4y+8MakCP7VU7P/o5gTqvu3cWnZYw3eQ2Qmj6E7pj8hWPHNUKljm6o jR8RLHkT1OVmIY/QWIGC/bNvjSXu+/vyYLjJni2Hu/OopHUDVb6qqGBSwuG+tsIaR3s+Cul1Uk4L2 Mjrh19+Hstu2R5iwHJXQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r7v8J-004q4L-0z; Tue, 28 Nov 2023 10:15:59 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r7uAu-004hSf-2R for linux-arm-kernel@bombadil.infradead.org; Tue, 28 Nov 2023 09:14:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type :In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID: Sender:Reply-To:Content-ID:Content-Description; bh=OP3ag60LowcdWpDh5If+yaV6nKcRij37x1mEkiYiuMo=; b=pJ1pqpq7ISxXdjTPGDaxTV418G CkyXuRnmOfGin+AqOYwd1zKQlgijEJdFSSrhmE+aYJfLzErDEeXxpCIEyB970UYs9lBFuAdcizC7Z QNQZulp+9z3Zglar24Wia8V7XwtE6acRVrMgLRbM96D4dpVKK13Y4x6HFTQb0+9di1TJlyzoubtgm rok2j2c0lUzMLLKhz/L6yj/9NU1tdZdprPC4LXgyevJBUf2mHzT0DqEz6kBD6nyVAkLbZJZ5tt87e aqCPtGfGbhcBf/aI+V6/0kuCssXJ3FOjPO+3ltvv/UxCiyLdrojcYRPoNQBTGRj+bUIzi5XyowIMr 7XvaNqPw==; Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r7uAn-00GZ8t-0S for linux-arm-kernel@lists.infradead.org; Tue, 28 Nov 2023 09:14:35 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 57CBBC15; Tue, 28 Nov 2023 01:15:11 -0800 (PST) Received: from [10.57.73.192] (unknown [10.57.73.192]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 33A823F73F; Tue, 28 Nov 2023 01:14:19 -0800 (PST) Message-ID: <7c4c8ab2-8eb2-472d-ad8d-9d6c20b2191c@arm.com> Date: Tue, 28 Nov 2023 09:14:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/14] mm: Batch-copy PTE ranges during fork() Content-Language: en-GB To: Barry Song <21cnbao@gmail.com> Cc: david@redhat.com, akpm@linux-foundation.org, andreyknvl@gmail.com, anshuman.khandual@arm.com, ardb@kernel.org, catalin.marinas@arm.com, dvyukov@google.com, glider@google.com, james.morse@arm.com, jhubbard@nvidia.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mark.rutland@arm.com, maz@kernel.org, oliver.upton@linux.dev, ryabinin.a.a@gmail.com, suzuki.poulose@arm.com, vincenzo.frascino@arm.com, wangkefeng.wang@huawei.com, will@kernel.org, willy@infradead.org, yuzenghui@huawei.com, yuzhao@google.com, ziy@nvidia.com References: <271f1e98-6217-4b40-bae0-0ac9fe5851cb@redhat.com> <20231127084217.13110-1-v-songbaohua@oppo.com> From: Ryan Roberts In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231128_091429_490312_9E652C5F X-CRM114-Status: GOOD ( 64.20 ) 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 T24gMjcvMTEvMjAyMyAyMDozNCwgQmFycnkgU29uZyB3cm90ZToKPiBPbiBUdWUsIE5vdiAyOCwg MjAyMyBhdCAxMjowN+KAr0FNIFJ5YW4gUm9iZXJ0cyA8cnlhbi5yb2JlcnRzQGFybS5jb20+IHdy b3RlOgo+Pgo+PiBPbiAyNy8xMS8yMDIzIDEwOjI4LCBCYXJyeSBTb25nIHdyb3RlOgo+Pj4gT24g TW9uLCBOb3YgMjcsIDIwMjMgYXQgMTE6MTHigK9QTSBSeWFuIFJvYmVydHMgPHJ5YW4ucm9iZXJ0 c0Bhcm0uY29tPiB3cm90ZToKPj4+Pgo+Pj4+IE9uIDI3LzExLzIwMjMgMDk6NTksIEJhcnJ5IFNv bmcgd3JvdGU6Cj4+Pj4+IE9uIE1vbiwgTm92IDI3LCAyMDIzIGF0IDEwOjM14oCvUE0gUnlhbiBS b2JlcnRzIDxyeWFuLnJvYmVydHNAYXJtLmNvbT4gd3JvdGU6Cj4+Pj4+Pgo+Pj4+Pj4gT24gMjcv MTEvMjAyMyAwODo0MiwgQmFycnkgU29uZyB3cm90ZToKPj4+Pj4+Pj4+ICsgICAgICAgICAgIGZv ciAoaSA9IDA7IGkgPCBucjsgaSsrLCBwYWdlKyspIHsKPj4+Pj4+Pj4+ICsgICAgICAgICAgICAg ICAgICAgaWYgKGFub24pIHsKPj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAv Kgo+Pj4+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIElmIHRoaXMgcGFnZSBt YXkgaGF2ZSBiZWVuIHBpbm5lZCBieSB0aGUKPj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKiBwYXJlbnQgcHJvY2VzcywgY29weSB0aGUgcGFnZSBpbW1lZGlhdGVseSBmb3IK Pj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgKiB0aGUgY2hpbGQgc28gdGhh dCB3ZSdsbCBhbHdheXMgZ3VhcmFudGVlIHRoZQo+Pj4+Pj4+Pj4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAqIHBpbm5lZCBwYWdlIHdvbid0IGJlIHJhbmRvbWx5IHJlcGxhY2VkIGluIHRo ZQo+Pj4+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIGZ1dHVyZS4KPj4+Pj4+ Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KPj4+Pj4+Pj4+ICsgICAgICAgICAg ICAgICAgICAgICAgICAgICBpZiAodW5saWtlbHkocGFnZV90cnlfZHVwX2Fub25fcm1hcCgKPj4+ Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGFnZSwg ZmFsc2UsIHNyY192bWEpKSkgewo+Pj4+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgaWYgKGkgIT0gMCkKPj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYnJlYWs7Cj4+Pj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAvKiBQYWdlIG1heSBiZSBwaW5uZWQsIHdlIGhhdmUgdG8gY29weS4gKi8K Pj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiBjb3B5 X3ByZXNlbnRfcGFnZSgKPj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgZHN0X3ZtYSwgc3JjX3ZtYSwgZHN0X3B0ZSwKPj4+Pj4+Pj4+ICsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjX3B0ZSwgYWRkciwgcnNzLCBw cmVhbGxvYywKPj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgcGFnZSk7Cj4+Pj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgfQo+Pj4+ Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHJzc1tNTV9BTk9OUEFHRVNdKys7Cj4+ Pj4+Pj4+PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgVk1fQlVHX09OKFBhZ2VBbm9uRXhj bHVzaXZlKHBhZ2UpKTsKPj4+Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgfSBlbHNlIHsKPj4+ Pj4+Pj4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICBwYWdlX2R1cF9maWxlX3JtYXAocGFn ZSwgZmFsc2UpOwo+Pj4+Pj4+Pj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIHJzc1ttbV9j b3VudGVyX2ZpbGUocGFnZSldKys7Cj4+Pj4+Pj4+PiArICAgICAgICAgICAgICAgICAgIH0KPj4+ Pj4+Pj4+ICAgICAgICAgICAgIH0KPj4+Pj4+Pj4+IC0gICAgICAgICAgIHJzc1tNTV9BTk9OUEFH RVNdKys7Cj4+Pj4+Pj4+PiAtICAgfSBlbHNlIGlmIChwYWdlKSB7Cj4+Pj4+Pj4+PiAtICAgICAg ICAgICBmb2xpb19nZXQoZm9saW8pOwo+Pj4+Pj4+Pj4gLSAgICAgICAgICAgcGFnZV9kdXBfZmls ZV9ybWFwKHBhZ2UsIGZhbHNlKTsKPj4+Pj4+Pj4+IC0gICAgICAgICAgIHJzc1ttbV9jb3VudGVy X2ZpbGUocGFnZSldKys7Cj4+Pj4+Pj4+PiArCj4+Pj4+Pj4+PiArICAgICAgICAgICBuciA9IGk7 Cj4+Pj4+Pj4+PiArICAgICAgICAgICBmb2xpb19yZWZfYWRkKGZvbGlvLCBucik7Cj4+Pj4+Pj4+ Cj4+Pj4+Pj4+IFlvdSdyZSBjaGFuZ2luZyB0aGUgb3JkZXIgb2YgbWFwY291bnQgdnMuIHJlZmNv dW50IGluY3JlbWVudC4gRG9uJ3QuCj4+Pj4+Pj4+IE1ha2Ugc3VyZSB5b3VyIHJlZmNvdW50ID49 IG1hcGNvdW50Lgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBZb3UgY2FuIGRvIHRoYXQgZWFzaWx5IGJ5IGRv aW5nIHRoZSBmb2xpb19yZWZfYWRkKGZvbGlvLCBucikgZmlyc3QgYW5kCj4+Pj4+Pj4+IHRoZW4g ZGVjcmVtZW50aW5nIGluIGNhc2Ugb2YgZXJyb3IgYWNjb3JkaW5nbHkuIEVycm9ycyBkdWUgdG8g cGlubmVkCj4+Pj4+Pj4+IHBhZ2VzIGFyZSB0aGUgY29ybmVyIGNhc2UuCj4+Pj4+Pj4+Cj4+Pj4+ Pj4+IEknbGwgbm90ZSB0aGF0IGl0IHdpbGwgbWFrZSBhIGxvdCBvZiBzZW5zZSB0byBoYXZlIGJh dGNoIHZhcmlhbnRzIG9mCj4+Pj4+Pj4+IHBhZ2VfdHJ5X2R1cF9hbm9uX3JtYXAoKSBhbmQgcGFn ZV9kdXBfZmlsZV9ybWFwKCkuCj4+Pj4+Pj4+Cj4+Pj4+Pj4KPj4+Pj4+PiBpIHN0aWxsIGRvbid0 IHVuZGVyc3RhbmQgd2h5IGl0IGlzIG5vdCBhIGVudGlyZSBtYXArMSwgYnV0IGFuIGluY3JlbWVu dAo+Pj4+Pj4+IGluIGVhY2ggYmFzZXBhZ2UuCj4+Pj4+Pgo+Pj4+Pj4gQmVjYXVzZSB3ZSBhcmUg UFRFLW1hcHBpbmcgdGhlIGZvbGlvLCB3ZSBoYXZlIHRvIGFjY291bnQgZWFjaCBpbmRpdmlkdWFs IHBhZ2UuCj4+Pj4+PiBJZiB3ZSBhY2NvdW50ZWQgdGhlIGVudGlyZSBmb2xpbywgd2hlcmUgd291 bGQgd2UgdW5hY2NvdW50IGl0PyBFYWNoIHBhZ2UgY2FuIGJlCj4+Pj4+PiB1bm1hcHBlZCBpbmRp dmlkdWFsbHkgKGUuZy4gbXVubWFwKCkgcGFydCBvZiB0aGUgZm9saW8pIHNvIG5lZWQgdG8gYWNj b3VudCBlYWNoCj4+Pj4+PiBwYWdlLiBXaGVuIFBNRCBtYXBwaW5nLCB0aGUgd2hvbGUgdGhpbmcg aXMgZWl0aGVyIG1hcHBlZCBvciB1bm1hcHBlZCwgYW5kIGl0cwo+Pj4+Pj4gYXRvbWljLCBzbyB3 ZSBjYW4gYWNjb3VudCB0aGUgZW50aXJlIHRoaW5nLgo+Pj4+Pgo+Pj4+PiBIaSBSeWFuLAo+Pj4+ Pgo+Pj4+PiBUaGVyZSBpcyBubyBwcm9ibGVtLiBmb3IgZXhhbXBsZSwgYSBsYXJnZSBmb2xpbyBp cyBlbnRpcmVseSBtYXBwZWQgaW4KPj4+Pj4gcHJvY2VzcyBBIHdpdGggQ09OUFRFLAo+Pj4+PiBh bmQgb25seSBwYWdlMiBpcyBtYXBwZWQgaW4gcHJvY2VzcyBCLgo+Pj4+PiB0aGVuIHdlIHdpbGwg aGF2ZQo+Pj4+Pgo+Pj4+PiBlbnRpcmVfbWFwID0gMAo+Pj4+PiBwYWdlMC5tYXAgPSAtMQo+Pj4+ PiBwYWdlMS5tYXAgPSAtMQo+Pj4+PiBwYWdlMi5tYXAgPSAwCj4+Pj4+IHBhZ2UzLm1hcCA9IC0x Cj4+Pj4+IC4uLi4KPj4+Pj4KPj4+Pj4+Cj4+Pj4+Pj4KPj4+Pj4+PiBhcyBsb25nIGFzIGl0IGlz IGEgQ09OVFBURSBsYXJnZSBmb2xpbywgdGhlcmUgaXMgbm8gbXVjaCBkaWZmZXJlbmNlIHdpdGgK Pj4+Pj4+PiBQTUQtbWFwcGVkIGxhcmdlIGZvbGlvLiBpdCBoYXMgYWxsIHRoZSBjaGFuY2UgdG8g YmUgRG91YmxlTWFwIGFuZCBuZWVkCj4+Pj4+Pj4gc3BsaXQuCj4+Pj4+Pj4KPj4+Pj4+PiBXaGVu IEEgYW5kIEIgc2hhcmUgYSBDT05UUFRFIGxhcmdlIGZvbGlvLCB3ZSBkbyBtYWR2aXNlKERPTlRO RUVEKSBvciBhbnkKPj4+Pj4+PiBzaW1pbGFyIHRoaW5ncyBvbiBhIHBhcnQgb2YgdGhlIGxhcmdl IGZvbGlvIGluIHByb2Nlc3MgQSwKPj4+Pj4+Pgo+Pj4+Pj4+IHRoaXMgbGFyZ2UgZm9saW8gd2ls bCBoYXZlIHBhcnRpYWxseSBtYXBwZWQgc3VicGFnZSBpbiBBIChhbGwgQ09OVFBFIGJpdHMKPj4+ Pj4+PiBpbiBhbGwgc3VicGFnZXMgbmVlZCB0byBiZSByZW1vdmVkIHRob3VnaCB3ZSBvbmx5IHVu bWFwIGEgcGFydCBvZiB0aGUKPj4+Pj4+PiBsYXJnZSBmb2xpb2FzIEhXIHJlcXVpcmVzIGNvbnNp c3RlbnQgQ09OVFBURXMpOyBhbmQgaXQgaGFzIGVudGlyZSBtYXAgaW4KPj4+Pj4+PiBwcm9jZXNz IEIoYWxsIFBURXMgYXJlIHN0aWxsIENPTlBURVMgaW4gcHJvY2VzcyBCKS4KPj4+Pj4+Pgo+Pj4+ Pj4+IGlzbid0IGl0IG1vcmUgc2Vuc2libGUgZm9yIHRoaXMgbGFyZ2UgZm9saW9zIHRvIGhhdmUg ZW50aXJlX21hcCA9IDAoZm9yCj4+Pj4+Pj4gcHJvY2VzcyBCKSwgYW5kIHN1YnBhZ2VzIHdoaWNo IGFyZSBzdGlsbCBtYXBwZWQgaW4gcHJvY2VzcyBBIGhhcyBtYXBfY291bnQKPj4+Pj4+PiA9MD8g KHN0YXJ0IGZyb20gLTEpLgo+Pj4+Pj4+Cj4+Pj4+Pj4+IEVzcGVjaWFsbHksIHRoZSBiYXRjaCB2 YXJpYW50IG9mIHBhZ2VfdHJ5X2R1cF9hbm9uX3JtYXAoKSB3b3VsZCBvbmx5Cj4+Pj4+Pj4+IGNo ZWNrIG9uY2UgaWYgdGhlIGZvbGlvIG1heWJlIHBpbm5lZCwgYW5kIGluIHRoYXQgY2FzZSwgeW91 IGNhbiBzaW1wbHkKPj4+Pj4+Pj4gZHJvcCBhbGwgcmVmZXJlbmNlcyBhZ2Fpbi4gU28geW91IGVp dGhlciBoYXZlIGFsbCBvciBubyBwdGVzIHRvIHByb2Nlc3MsCj4+Pj4+Pj4+IHdoaWNoIG1ha2Vz IHRoYXQgY29kZSBlYXNpZXIuCj4+Pj4+Pgo+Pj4+Pj4gSSdtIGFmcmFpZCB0aGlzIGRvZXNuJ3Qg bWFrZSBzZW5zZSB0byBtZS4gUGVyaGFwcyBJJ3ZlIG1pc3VuZGVyc3Rvb2QuIEJ1dAo+Pj4+Pj4g ZnVuZGFtZW50YWxseSB5b3UgY2FuIG9ubHkgdXNlIGVudGlyZV9tYXBjb3VudCBpZiBpdHMgb25s eSBwb3NzaWJsZSB0byBtYXAgYW5kCj4+Pj4+PiB1bm1hcCB0aGUgd2hvbGUgZm9saW8gYXRvbWlj YWxseS4KPj4+Pj4KPj4+Pj4KPj4+Pj4KPj4+Pj4gTXkgcG9pbnQgaXMgdGhhdCBDT05UUEVzIHNo b3VsZCBlaXRoZXIgYWxsLXNldCBpbiBhbGwgMTYgUFRFcyBvciBhbGwgYXJlIGRyb3BwZWQKPj4+ Pj4gaW4gMTYgUFRFcy4gaWYgYWxsIFBURXMgaGF2ZSBDT05ULCBpdCBpcyBlbnRpcmVseSBtYXBw ZWQ7IG90aGVyd2lzZSwKPj4+Pj4gaXQgaXMgcGFydGlhbGx5Cj4+Pj4+IG1hcHBlZC4gaWYgYSBs YXJnZSBmb2xpbyBpcyBtYXBwZWQgaW4gb25lIHByb2Nlc3NlcyB3aXRoIGFsbCBDT05UUFRFcwo+ Pj4+PiBhbmQgbWVhbndoaWxlIGluIGFub3RoZXIgcHJvY2VzcyB3aXRoIHBhcnRpYWwgbWFwcGlu Zyh3L28gQ09OVFBURSksIGl0IGlzCj4+Pj4+IERvdWJsZU1hcHBlZC4KPj4+Pgo+Pj4+IFRoZXJl IGFyZSAyIHByb2JsZW1zIHdpdGggeW91ciBwcm9wb3NhbCwgYXMgSSBzZWUgaXQ7Cj4+Pj4KPj4+ PiAxKSB0aGUgY29yZS1tbSBpcyBub3QgZW5saWdodGVuZWQgZm9yIENPTlRQVEUgbWFwcGluZ3Mu IEFzIGZhciBhcyBpdCBpcwo+Pj4+IGNvbmNlcm5lZCwgaXRzIGp1c3QgbWFwcGluZyBhIGJ1bmNo IG9mIFBURXMuIFNvIGl0IGhhcyBubyBob29rIHRvIGluYy9kZWMKPj4+PiBlbnRpcmVfbWFwY291 bnQuIFRoZSBhcmNoIGNvZGUgaXMgb3Bwb3J0dW5pc3RpY2FsbHkgYW5kICp0cmFuc3BhcmVudGx5 KiBtYW5hZ2luZwo+Pj4+IHRoZSBDT05UX1BURSBiaXQuCj4+Pj4KPj4+PiAyKSBUaGVyZSBpcyBu b3RoaW5nIHRvIHNheSBhIGZvbGlvIGlzbid0ICpiaWdnZXIqIHRoYW4gdGhlIGNvbnRwdGUgYmxv Y2s7IGl0IG1heQo+Pj4+IGJlIDEyOEsgYW5kIGJlIG1hcHBlZCB3aXRoIDIgY29udHB0ZSBibG9j a3MuIE9yIGV2ZW4gYSBQVEUtbWFwcGVkIFRIUCAoMk0pIGFuZAo+Pj4+IGJlIG1hcHBlZCB3aXRo IDMyIGNvbnRwdGUgYmxvY2tzLiBTbyB5b3UgY2FuJ3Qgc2F5IGl0IGlzIGVudGlyZWx5IG1hcHBl ZAo+Pj4+IHVubGVzcy91bnRpbCBBTEwgb2YgdGhvc2UgYmxvY2tzIGFyZSBzZXQgdXAuIEFuZCB0 aGVuIG9mIGNvdXJzZSBlYWNoIGJsb2NrIGNvdWxkCj4+Pj4gYmUgdW5tYXBwZWQgdW5hdG9taWNh bGx5Lgo+Pj4+Cj4+Pj4gRm9yIHRoZSBQTUQgY2FzZSB0aGVyZSBhcmUgYWN0dWFsbHkgMiBwcm9w ZXJ0aWVzIHRoYXQgYWxsb3cgdXNpbmcgdGhlCj4+Pj4gZW50aXJlX21hcGNvdW50IG9wdGltaXph dGlvbjsgSXQncyBhdG9taWNhbGx5IG1hcHBlZC91bm1hcHBlZCB0aHJvdWdoIHRoZSBQTUQKPj4+ PiBhbmQgd2Uga25vdyB0aGF0IHRoZSBmb2xpbyBpcyBleGFjdGx5IFBNRCBzaXplZCAoc2luY2Ug aXQgbXVzdCBiZSBhdCBsZWFzdCBQTUQKPj4+PiBzaXplZCB0byBiZSBhYmxlIHRvIG1hcCBpdCB3 aXRoIHRoZSBQTUQsIGFuZCB3ZSBkb24ndCBhbGxvY2F0ZSBUSFBzIGFueSBiaWdnZXIKPj4+PiB0 aGFuIFBNRCBzaXplKS4gU28gb25lIFBNRCBtYXAgb3IgdW5tYXAgb3BlcmF0aW9uIGNvcnJlc3Bv bmRzIHRvIGV4YWN0bHkgb25lCj4+Pj4gKmVudGlyZSogbWFwIG9yIHVubWFwLiBUaGF0IGlzIG5v dCB0cnVlIHdoZW4gd2UgYXJlIFBURSBtYXBwaW5nLgo+Pj4KPj4+IHdlbGwuIFRoYW5rcyBmb3Ig Y2xhcmlmaWNhdGlvbi4gYmFzZWQgb24gdGhlIGFib3ZlIGRlc2NyaXB0aW9uLCBpIGFncmVlIHRo ZQo+Pj4gY3VycmVudCBjb2RlIG1pZ2h0IG1ha2UgbW9yZSBzZW5zZSBieSBhbHdheXMgdXNpbmcg bWFwY291bnQgaW4gc3VicGFnZS4KPj4+Cj4+PiBJIGdhdmUgbXkgcHJvcG9zYWxzIGFzICBJIHRo b3VnaHQgd2Ugd2VyZSBhbHdheXMgQ09OVFBURSBzaXplIGZvciBzbWFsbC1USFAKPj4+IHRoZW4g d2UgY291bGQgZHJvcCB0aGUgbG9vcCB0byBpdGVyYXRlIDE2IHRpbWVzIHJtYXAuIGlmIHdlIGRv IGl0Cj4+PiBlbnRpcmVseSwgd2Ugb25seQo+Pj4gbmVlZCB0byBkbyBkdXAgcm1hcCBvbmNlIGZv ciBhbGwgMTYgUFRFcyBieSBpbmNyZWFzaW5nIGVudGlyZV9tYXAuCj4+Cj4+IFdlbGwgaXRzIGFs d2F5cyBnb29kIHRvIGhhdmUgdGhlIGRpc2N1c3Npb24gLSBzbyB0aGFua3MgZm9yIHRoZSBpZGVh cy4gSSB0aGluawo+PiB0aGVyZSBpcyBhIGJpZ2dlciBxdWVzdGlvbiBsdXJraW5nIGhlcmU7IHNo b3VsZCB3ZSBiZSBleHBvc2luZyB0aGUgY29uY2VwdCBvZgo+PiBjb250cHRlIG1hcHBpbmdzIHRv IHRoZSBjb3JlLW1tIHJhdGhlciB0aGFuIGJ1cnlpbmcgaXQgaW4gdGhlIGFybTY0IGFyY2ggY29k ZT8KPj4gSSdtIGNvbmZpZGVudCB0aGF0IHdvdWxkIGJlIGEgaHVnZSBhbW91bnQgb2YgZWZmb3J0 IGFuZCB0aGUgZW5kIHJlc3VsdCB3b3VsZCBiZQo+PiBzaW1pbGFyIHBlcmZvcm1hY2UgdG8gd2hh dCB0aGlzIGFwcHJvYWNoIGdpdmVzLiBPbmUgcG90ZW50aWFsIGJlbmVmaXQgb2YgbGV0dGluZwo+ PiBjb3JlLW1tIGNvbnRyb2wgaXQgaXMgdGhhdCBpdCB3b3VsZCBhbHNvIGdpdmUgY29udHJvbCB0 byBjb3JlLW1tIG92ZXIgdGhlCj4+IGdyYW51bGFyaXR5IG9mIGFjY2Vzcy9kaXJ0eSByZXBvcnRp bmcgKG15IGFwcHJvYWNoIGltcGxpY2l0bHkgdGllcyBpdCB0byB0aGUKPj4gZm9saW8pLiBIYXZp bmcgc3ViLWZvbGlvIGFjY2VzcyB0cmFja2luZyBfY291bGRfIHBvdGVudGlhbGx5IGhlbHAgd2l0 aCBmdXR1cmUKPj4gd29yayB0byBtYWtlIFRIUCBzaXplIHNlbGVjdGlvbiBhdXRvbWF0aWMsIGJ1 dCB3ZSBhcmUgbm90IHRoZXJlIHlldCwgYW5kIEkgdGhpbmsKPj4gdGhlcmUgYXJlIG90aGVyIChz aW1wbGVyKSB3YXlzIHRvIGFjaGlldmUgdGhlIHNhbWUgdGhpbmcuIFNvIG15IHZpZXcgaXMgdGhh dAo+PiBfbm90XyBleHBvc2luZyBpdCB0byBjb3JlLW1tIGlzIHRoZSByaWdodCB3YXkgZm9yIG5v dy4KPiAKPiBIaSBSeWFuLAo+IAo+IFdlKE9QUE8pIHN0YXJ0ZWQgYSBzaW1pbGFyIHByb2plY3Qg bGlrZSB5b3UgZXZlbiBiZWZvcmUgZm9saW8gd2FzIGltcG9ydGVkIHRvCj4gbWFpbmxpbmUsIHdl IGhhdmUgZGVwbG95ZWQgdGhlIGR5bmFtaWMgaHVnZXBhZ2UodGhhdCBpcyBob3cgd2UgbmFtZSBp dCkKPiBvbiBtaWxsaW9ucyBvZiBtb2JpbGUgcGhvbmVzIG9uIHJlYWwgcHJvZHVjdHMgYW5kIGtl cm5lbHMgYmVmb3JlIDUuMTYsICBtYWtpbmcKPiBhIGh1Z2Ugc3VjY2VzcyBvbiBwZXJmb3JtYW5j ZSBpbXByb3ZlbWVudC4gZm9yIGV4YW1wbGUsIHlvdSBtYXkKPiBmaW5kIHRoZSBvdXQtb2YtdHJl ZSA1LjE1IHNvdXJjZSBjb2RlIGhlcmUKCk9oIHdvdywgdGhhbmtzIGZvciByZWFjaGluZyBvdXQg YW5kIGV4cGxhaW5pbmcgdGhpcyAtIEkgaGF2ZSB0byBhZG1pdCBJIGZlZWwKZW1iYXJyYXNzZWQg dGhhdCBJIGNsZWFybHkgZGlkbid0IGRvIGVub3VnaCByZXNlYXJjaCBvbiB0aGUgcHJpb3IgYXJ0 IGJlY2F1c2UgSQp3YXNuJ3QgYXdhcmUgb2YgeW91ciB3b3JrLiBTbyBzb3JyeSBhYm91dCB0aGF0 LgoKSSBzZW5zZWQgdGhhdCB5b3UgaGFkIGEgZGlmZmVyZW50IG1vZGVsIGZvciBob3cgdGhpcyBz aG91bGQgd29yayB2cyB3aGF0IEkndmUKaW1wbGVtZW50ZWQgYW5kIG5vdyBJIHVuZGVyc3RhbmQg d2h5IDopLiBJJ2xsIHJldmlldyB5b3VyIHN0dWZmIGFuZCBJJ20gc3VyZQpJJ2xsIGhhdmUgcXVl c3Rpb25zLiBJJ20gc3VyZSBlYWNoIHNvbHV0aW9uIGhhcyBwcm9zIGFuZCBjb25zLgoKCj4gCj4g aHR0cHM6Ly9naXRodWIuY29tL09uZVBsdXNPU1MvYW5kcm9pZF9rZXJuZWxfb25lcGx1c19zbTg1 NTAvdHJlZS9vbmVwbHVzL3NtODU1MF91XzE0LjAuMF9vbmVwbHVzMTEKPiAKPiBPdXIgbW9kaWZp Y2F0aW9uIG1pZ2h0IG5vdCBiZSBzbyBjbGVhbiBhbmQgaGFzIGxvdHMgb2Ygd29ya2Fyb3VuZHMK PiBqdXN0IGZvciB0aGUgc3RhYmlsaXR5IG9mIHByb2R1Y3RzCj4gCj4gV2UgbWFpbmx5IGhhdmUK PiAKPiAxLiBodHRwczovL2dpdGh1Yi5jb20vT25lUGx1c09TUy9hbmRyb2lkX2tlcm5lbF9vbmVw bHVzX3NtODU1MC9ibG9iL29uZXBsdXMvc204NTUwX3VfMTQuMC4wX29uZXBsdXMxMS9tbS9jb250 X3B0ZV9odWdlcGFnZS5jCj4gCj4gc29tZSBDT05UUFRFIGhlbHBlcnMKPiAKPiAyLmh0dHBzOi8v Z2l0aHViLmNvbS9PbmVQbHVzT1NTL2FuZHJvaWRfa2VybmVsX29uZXBsdXNfc204NTUwL2Jsb2Iv b25lcGx1cy9zbTg1NTBfdV8xNC4wLjBfb25lcGx1czExL2luY2x1ZGUvbGludXgvbW0uaAo+IAo+ IHNvbWUgRHluYW1pYyBIdWdlcGFnZSBBUElzCj4gCj4gMy4gaHR0cHM6Ly9naXRodWIuY29tL09u ZVBsdXNPU1MvYW5kcm9pZF9rZXJuZWxfb25lcGx1c19zbTg1NTAvYmxvYi9vbmVwbHVzL3NtODU1 MF91XzE0LjAuMF9vbmVwbHVzMTEvbW0vbWVtb3J5LmMKPiAKPiBtb2RpZmllZCBhbGwgcGFnZSBm YXVsdHMgdG8gc3VwcG9ydAo+ICAgICAgKDEpLiBhbGxvY2F0aW9uIG9mIGh1Z2VwYWdlIG9mIDY0 S0IgaW4gZG9fYW5vbl9wYWdlCgpNeSBTbWFsbC1TaXplZCBUSFAgcGF0Y2ggc2V0IGlzIGhhbmRs aW5nIHRoZSBlcXVpdmFsZW50IG9mIHRoaXMuCgo+ICAgICAgKDIpLiBDb1cgaHVnZXBhZ2UgaW4g ZG9fd3BfcGFnZQoKVGhpcyBpc24ndCBoYW5kbGVkIHlldCBpbiBteSBwYXRjaCBzZXQ7IHRoZSBv cmlnaW5hbCBSRkMgaW1wbGVtZW50ZWQgaXQgYnV0IEkKcmVtb3ZlZCBpdCBpbiBvcmRlciB0byBz dHJpcCBiYWNrIHRvIHRoZSBlc3NlbnRpYWwgY29tcGxleGl0eSBmb3IgdGhlIGluaXRpYWwKc3Vi bWlzc2lvbi4gRGF2aWRIIGhhcyBiZWVuIHdvcmtpbmcgb24gYSBwcmVjaXNlIHNoYXJlZCB2cyBl eGNsdXNpdmUgbWFwCnRyYWNraW5nIG1lY2hhbmlzbSAtIGlmIHRoYXQgZ29lcyBpbiwgaXQgd2ls bCBtYWtlIENvV2luZyBsYXJnZSBmb2xpb3Mgc2ltcGxlci4KT3V0IG9mIGludGVyZXN0LCB3aGF0 IHdvcmtsb2FkcyBiZW5lZml0IG1vc3QgZnJvbSB0aGlzPwoKPiAgICAgICgzKS4gY29weSBDT05Q VEVzIGluIGNvcHlfcHRlX3JhbmdlCgpBcyBkaXNjdXNzZWQgdGhpcyBpcyBkb25lIGFzIHBhcnQg b2YgdGhlIGNvbnRwdGUgcGF0Y2ggc2V0LCBidXQgaXRzIG5vdCBqdXN0IGEKc2ltcGxlIGNvcHk7 IHRoZSBhcmNoIGNvZGUgd2lsbCBub3RpY2UgYW5kIHNldCB0aGUgQ09OVF9QVEUgYml0IGFzIG5l ZWRlZC4KCj4gICAgICAoNCkuIGFsbG9jYXRlIGFuZCBzd2FwLWluIEh1Z2VwYWdlIGFzIGEgd2hv bGUgaW4gZG9fc3dhcF9wYWdlCgpUaGlzIGlzIGdvaW5nIHRvIGJlIGEgcHJvYmxlbSBidXQgSSBo YXZlbid0IGV2ZW4gbG9va2VkIGF0IHRoaXMgcHJvcGVybHkgeWV0LgpUaGUgYWR2aWNlIHNvIGZh ciBoYXMgYmVlbiB0byBjb250aW51ZSB0byBzd2FwLWluIHNtYWxsIHBhZ2VzIG9ubHksIGJ1dCBp bXByb3ZlCmtodWdlcGFnZWQgdG8gY29sbGFwc2UgdG8gc21hbGwtc2l6ZWQgVEhQLiBJJ2xsIHRh a2UgYSBsb29rIGF0IHlvdXIgY29kZSB0bwp1bmRlcnN0YW5kIGhvdyB5b3UgZGlkIHRoaXMuCgo+ IAo+IDQuIGh0dHBzOi8vZ2l0aHViLmNvbS9PbmVQbHVzT1NTL2FuZHJvaWRfa2VybmVsX29uZXBs dXNfc204NTUwL2Jsb2Ivb25lcGx1cy9zbTg1NTBfdV8xNC4wLjBfb25lcGx1czExL21tL3Ztc2Nh bi5jCj4gaHR0cHM6Ly9naXRodWIuY29tL09uZVBsdXNPU1MvYW5kcm9pZF9rZXJuZWxfb25lcGx1 c19zbTg1NTAvYmxvYi9vbmVwbHVzL3NtODU1MF91XzE0LjAuMF9vbmVwbHVzMTEvbW0vcm1hcC5j Cj4gCj4gcmVjbGFpbSBodWdlcGFnZSBhcyBhIHdob2xlIGFuZCBMUlUgb3B0aW1pemF0aW9uIGZv ciA2NEtCIGR5bmFtaWMgaHVnZXBhZ2UuCgpJIHRoaW5rIHRoaXMgaXMgYWxsIG5hdHVyYWxseSBo YW5kbGVkIGJ5IHRoZSBmb2xpbyBjb2RlIHRoYXQgZXhpc3RzIGluIG1vZGVybgprZXJuZWxzPwoK PiAKPiBTbyB3ZSBhcmUgMTAwJSBpbnRlcmVzdGVkIGluIHlvdXIgcGF0Y2hzZXQgYW5kIGhvcGUg aXQgY2FuIGZpbmQgYSB3YXkKPiB0byBsYW5kIG9uIHRoZQo+IG1haW5saW5lLCB0aHVzIGRlY3Jl YXNpbmcgYWxsIHRoZSBjb3N0IHdlIGhhdmUgdG8gbWFpbnRhaW4gb3V0LW9mLXRyZWUKPiBjb2Rl IGZyb20gYQo+IGtlcm5lbCB0byBhbm90aGVyIGtlcm5lbCB2ZXJzaW9uIHdoaWNoIHdlIGhhdmUg ZG9uZSBvbiBhIGNvdXBsZSBvZgo+IGtlcm5lbCB2ZXJzaW9ucwo+IGJlZm9yZSA1LjE2LiBGaXJt bHksIHdlIGFyZSAxMDAlIHN1cHBvcnRpdmUgb2YgbGFyZ2UgYW5vbiBmb2xpb3MKPiB0aGluZ3Mg eW91IGFyZSBsZWFkaW5nLgoKVGhhdCdzIGdyZWF0IHRvIGhlYXIhIE9mIGNvdXJzZSBSZXZpZXdl ZC1CeSdzIGFuZCBUZXN0ZWQtQnkncyB3aWxsIGFsbCBoZWxwIG1vdmUKaXQgY2xvc2VyIDopLiBJ ZiB5b3UgaGFkIGFueSBhYmlsaXR5IHRvIGRvIGFueSBBL0IgcGVyZm9ybWFuY2UgdGVzdGluZywg aXQgd291bGQKYmUgdmVyeSBpbnRlcmVzdGluZyB0byBzZWUgaG93IHRoaXMgc3RhY2tzIHVwIGFn YWluc3QgeW91ciBzb2x1dGlvbiAtIGlmIHRoZXJlCmFyZSBnYXBzIGl0IHdvdWxkIGJlIGdvb2Qg dG8ga25vdyB3aGVyZSBhbmQgZGV2ZWxvcCBhIHBsYW4gdG8gcGx1ZyB0aGUgZ2FwLgoKPiAKPiBB IGJpZyBwYWluIHdhcyB3ZSBmb3VuZCBsb3RzIG9mIHJhY2VzIGVzcGVjaWFsbHkgb24gQ09OVFBU RSB1bmZvbGRpbmcKPiBhbmQgZXNwZWNpYWxseSBhIHBhcnQKPiBvZiBiYXNlcGFnZXMgcmFuIGF3 YXkgZnJvbSB0aGUgMTYgQ09OUFRFcyBncm91cCBzaW5jZSB1c2Vyc3BhY2UgaXMKPiBhbHdheXMg d29ya2luZwo+IG9uIGJhc2VwYWdlcywgaGF2aW5nIG5vIGlkZWEgb2Ygc21hbGwtVEhQLiAgV2Ug cmFuIG91ciBjb2RlIG9uIG1pbGxpb25zIG9mCj4gcmVhbCBwaG9uZXMsIGFuZCBub3cgd2UgaGF2 ZSBnb3QgdGhlbSBmaXhlZCAob3IgbWF5YmUgImNhbid0IHJlcHJvZHVjZSIpLAo+IG5vIG91dHN0 YW5kaW5nIGlzc3VlLgoKSSdtIGdvaW5nIHRvIGJlIGJyYXZlIGFuZCBzYXkgdGhhdCBteSBzb2x1 dGlvbiBzaG91bGRuJ3Qgc3VmZmVyIGZyb20gdGhlc2UKcHJvYmxlbXM7IGJ1dCBvZiBjb3Vyc2Ug dGhlIHByb29mIGlzIG9ubHkgaW4gdGhlIHRlc3RpbmcuIEkgZGlkIGEgbG90IG9mIHdvcmsKd2l0 aCBvdXIgYXJjaGl0ZWN0dXJlIGdyb3VwIGFuZCBtaWNybyBhcmNoaXRlY3RzIHRvIGRldGVybWlu ZSBleGFjdGx5IHdoYXQgaXMKYW5kIGlzbid0IHNhZmU7IFdlIGV2ZW4gdGlnaHRlbmVkIHRoZSBB cm0gQVJNIHNwZWMgdmVyeSBzdWJ0bGVseSB0byBhbGxvdyB0aGUKb3B0aW1pemF0aW9uIGluIHBh dGNoIDEzIChzZWUgdGhlIGNvbW1pdCBsb2cgZm9yIGRldGFpbHMpLiBPZiBjb3Vyc2UgdGhpcyBo YXMKYWxsIGJlZW4gY2hlY2tlZCB3aXRoIHBhcnRuZXJzIGFuZCB3ZSBhcmUgY29uZmlkZW50IHRo YXQgYWxsIGV4aXN0aW5nCmltcGxlbWVudGF0aW9ucyBjb25mb3JtIHRvIHRoZSBtb2RpZmllZCB3 b3JkaW5nLgoKPiAKPiBQYXJ0aWN1bGFybHkgZm9yIHRoZSBybWFwIGlzc3VlIHdlIGFyZSBkaXNj dXNzaW5nLCBvdXIgb3V0LW9mLXRyZWUgaXMKPiB1c2luZyB0aGUgZW50aXJlX21hcCBmb3IKPiBD T05UUFRFIGluIHRoZSB3YXkgSSBzZW50IHRvIHlvdS4gQnV0IEkgZ3Vlc3Mgd2UgY2FuIGxlYXJu IGZyb20geW91IHRvIGRlY291cGxlCj4gQ09OVFBURSBmcm9tIG1tLWNvcmUuCj4gCj4gV2UgYXJl IGRvaW5nIHRoaXMgaW4gbW0vbWVtb3J5LmMKPiAKPiBjb3B5X3ByZXNlbnRfY29udF9wdGUoc3Ry dWN0IHZtX2FyZWFfc3RydWN0ICpkc3Rfdm1hLCBzdHJ1Y3QKPiB2bV9hcmVhX3N0cnVjdCAqc3Jj X3ZtYSwKPiBwdGVfdCAqZHN0X3B0ZSwgcHRlX3QgKnNyY19wdGUsIHVuc2lnbmVkIGxvbmcgYWRk ciwgaW50ICpyc3MsCj4gc3RydWN0IHBhZ2UgKipwcmVhbGxvYykKPiB7Cj4gICAgICAgc3RydWN0 IG1tX3N0cnVjdCAqc3JjX21tID0gc3JjX3ZtYS0+dm1fbW07Cj4gICAgICAgdW5zaWduZWQgbG9u ZyB2bV9mbGFncyA9IHNyY192bWEtPnZtX2ZsYWdzOwo+ICAgICAgIHB0ZV90IHB0ZSA9ICpzcmNf cHRlOwo+ICAgICAgIHN0cnVjdCBwYWdlICpwYWdlOwo+IAo+ICAgICAgICBwYWdlID0gdm1fbm9y bWFsX3BhZ2Uoc3JjX3ZtYSwgYWRkciwgcHRlKTsKPiAgICAgICAuLi4KPiAKPiAgICAgIGdldF9w YWdlKHBhZ2UpOwo+ICAgICAgcGFnZV9kdXBfcm1hcChwYWdlLCB0cnVlKTsgICAvLyBhbiBlbnRp cmUgZHVwX3JtYXAgYXMgeW91IGNhbgo+IHNlZS4uLi4uLi4uLi4uLi4KPiAgICAgIHJzc1ttbV9j b3VudGVyKHBhZ2UpXSArPSBIUEFHRV9DT05UX1BURV9OUjsKPiB9Cj4gCj4gYW5kIHdlIGhhdmUg YSBzcGxpdCBpbiBtbS9jb250X3B0ZV9odWdlcGFnZS5jIHRvIGhhbmRsZSBwYXJ0aWFsbHkgdW5t YXAsCj4gCj4gc3RhdGljIHZvaWQgX19zcGxpdF9odWdlX2NvbnRfcHRlX2xvY2tlZChzdHJ1Y3Qg dm1fYXJlYV9zdHJ1Y3QgKnZtYSwgcHRlX3QgKnB0ZSwKPiB1bnNpZ25lZCBsb25nIGhhZGRyLCBi b29sIGZyZWV6ZSkKPiB7Cj4gLi4uCj4gICAgICAgICAgICBpZiAoY29tcG91bmRfbWFwY291bnQo aGVhZCkgPiAxICYmICFUZXN0U2V0UGFnZURvdWJsZU1hcChoZWFkKSkgewo+ICAgICAgICAgICAg ICAgICAgIGZvciAoaSA9IDA7IGkgPCBIUEFHRV9DT05UX1BURV9OUjsgaSsrKQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGF0b21pY19pbmMoJmhlYWRbaV0uX21hcGNvdW50KTsKPiAgICAg ICAgICAgICAgICAgIGF0b21pY19sb25nX2luYygmY29udF9wdGVfZG91YmxlX21hcF9jb3VudCk7 Cj4gICAgICAgICAgICB9Cj4gCj4gCj4gICAgICAgICAgICAgaWYgKGF0b21pY19hZGRfbmVnYXRp dmUoLTEsIGNvbXBvdW5kX21hcGNvdW50X3B0cihoZWFkKSkpIHsKPiAgICAgICAgICAgICAgIC4u Lgo+IH0KPiAKPiBJIGFtIG5vdCBzZWxsaW5nIG91ciBzb2x1dGlvbiBhbnkgbW9yZSwgYnV0IGp1 c3Qgc2hvd2luZyB5b3Ugc29tZSBkaWZmZXJlbmNlcyB3ZQo+IGhhdmUgOi0pCgpPSywgSSB1bmRl cnN0YW5kIHdoYXQgeW91IHdlcmUgc2F5aW5nIG5vdy4gSSdtIGN1cnJlbnRseSBzdHJ1Z2dsaW5n IHRvIHNlZSBob3cKdGhpcyBjb3VsZCBmaXQgaW50byBteSBtb2RlbC4gRG8geW91IGhhdmUgYW55 IHdvcmtsb2FkcyBhbmQgbnVtYmVycyBvbiBwZXJmCmltcHJvdmVtZW50IG9mIHVzaW5nIGVudGly ZV9tYXBjb3VudD8KCj4gCj4+Cj4+Pgo+Pj4gQlRXLCBJIGhhdmUgY29uY2VybnMgdGhhdCBhIHZh cmlhYmxlIHNtYWxsLVRIUCBzaXplIHdpbGwgcmVhbGx5IHdvcmsKPj4+IGFzIHVzZXJzcGFjZQo+ Pj4gaXMgcHJvYmFibHkgZnJpZW5kbHkgdG8gb25seSBvbmUgZml4ZWQgc2l6ZS4gZm9yIGV4YW1w bGUsIHVzZXJzcGFjZQo+Pj4gaGVhcCBtYW5hZ2VtZW50Cj4+PiBtaWdodCBiZSBvcHRpbWl6ZWQg dG8gYSBzaXplIGZvciBmcmVlaW5nIG1lbW9yeSB0byB0aGUga2VybmVsLiBpdCBpcwo+Pj4gdmVy eSBkaWZmaWN1bHQKPj4+IGZvciB0aGUgaGVhcCB0byBhZGFwdCB0byB2YXJpb3VzIHNpemVzIGF0 IHRoZSBzYW1lIHRpbWUuIGZyZXF1ZW50IHVubWFwL2ZyZWUKPj4+IHNpemUgbm90IGVxdWFsIHdp dGgsIGFuZCBwYXJ0aWN1bGFybHkgc21hbGxlciB0aGFuIHNtYWxsLVRIUCBzaXplIHdpbGwKPj4+ IGRlZmVhdCBhbGwKPj4+IGVmZm9ydHMgdG8gdXNlIHNtYWxsLVRIUC4KPj4KPj4gSSdsbCBhZG1p dCB0byBub3Qga25vd2luZyBhIGh1Z2UgYW1vdW50IGFib3V0IHVzZXIgc3BhY2UgYWxsb2NhdG9y cy4gQnV0IEkgd2lsbAo+PiBzYXkgdGhhdCBhcyBjdXJyZW50bHkgZGVmaW5lZCwgdGhlIHNtYWxs LXNpemVkIFRIUCBpbnRlcmZhY2UgdG8gdXNlciBzcGFjZQo+PiBhbGxvd3MgYSBzeXNhZG1pbiB0 byBzcGVjaWZpY2FsbHkgZW5hYmxlIHRoZSBzZXQgb2Ygc2l6ZXMgdGhhdCB0aGV5IHdhbnQ7IHNv IGEKPj4gc2luZ2xlIHNpemUgY2FuIGJlIGVuYWJsZWQuIEknbSBkaWxpYmVyYXRlbHkgcHVudGlu ZyB0aGF0IGRlY2lzaW9uIGF3YXkgZnJvbSB0aGUKPj4ga2VybmVsIGZvciBub3cuCj4gCj4gQmFz aWNhbGx5LCB1c2Vyc3BhY2UgaGVhcCBsaWJyYXJ5IGhhcyBhIFBBR0VTSVpFIHNldHRpbmcgYW5k IGFsbG93cyB1c2Vycwo+IHRvIGFsbG9jYXRlL2ZyZWUgYWxsIGtpbmRzIG9mIHNtYWxsIG9iamVj dHMgc3VjaCBhcyAxNiwzMiw2NCwxMjgsMjU2LDUxMiBldGMuCj4gVGhlIGRlZmF1bHQgc2l6ZSBp cyBmb3Igc3VyZSBlcXVhbCB0byB0aGUgYmFzZXBhZ2UgU0laRS4gb25jZSBzb21lIG9iamVjdHMg YXJlCj4gZnJlZWQgYnkgZnJlZSgpIGFuZCBsaWJjIGdldCBhIGZyZWUgInBhZ2UiLCB1c2Vyc3Bh Y2UgaGVhcCBsaWJyYXJpZXMgbWlnaHQgZnJlZQo+IHRoZSBQQUdFU0laRSBwYWdlIHRvIGtlcm5l bCBieSB0aGluZ3MgbGlrZSBNQURWX0RPTlRORUVELCB0aGVuIHphcF9wdGVfcmFuZ2UoKS4KPiBp dCBpcyBxdWl0ZSBzaW1pbGFyIHdpdGgga2VybmVsIHNsYWIuCj4gCj4gc28gaW1hZ2luZSB3ZSBo YXZlIHNtYWxsLVRIUCBub3csIGJ1dCB1c2Vyc3BhY2UgbGlicmFyaWVzIGhhdmUgKk5PKgo+IGlk ZWEgYXQgYWxsLCAgc28gaXQgY2FuIGZyZXF1ZW50bHkgY2F1c2UgdW5mb2xkaW5nLgo+IAo+Pgo+ PiBGV0lXLCBNeSBleHBlcmllbmNlIHdpdGggdGhlIFNwZWVkb21ldGVyL0phdmFTY3JpcHQgdXNl IGNhc2UgaXMgdGhhdCBwZXJmb3JtYW5jZQo+PiBpcyBhIGxpdHRsZSBiaXQgYmV0dGVyIHdoZW4g ZW5hYmxpbmcgNjQrMzIrMTZLIHZzIGp1c3QgNjRLIFRIUC4KPj4KPj4gRnVuY3Rpb25hbGx5LCBp dCB3aWxsIG5vdCBtYXR0ZXIgaWYgdGhlIGFsbG9jYXRvciBpcyBub3QgZW5saWdodGVuZWQgZm9y IHRoZSBUSFAKPj4gc2l6ZTsgaXQgY2FuIGNvbnRpbnVlIHRvIGZyZWUsIGFuZCBpZiBhIHBhcnRp YWwgZm9saW8gaXMgdW5tYXBwZWQgaXQgaXMgcHV0IG9uCj4+IHRoZSBkZWZlcnJlZCBzcGxpdCBs aXN0LCB0aGVuIHVuZGVyIG1lbW9yeSBwcmVzc3VyZSBpdCBpcyBzcGxpdCBhbmQgdGhlIHVudXNl ZAo+PiBwYWdlcyBhcmUgcmVjbGFpbWVkLiBJIGd1ZXNzIHRoaXMgaXMgdGhlIGJpdCB5b3UgYXJl IGNvbmNlcm5lZCBhYm91dCBoYXZpbmcgYQo+PiBwZXJmb3JtYW5jZSBpbXBhY3Q/Cj4gCj4gcmln aHQuIElmIHRoaXMgaXMgaGFwcGVuaW5nIG9uIHRoZSBtYWpvcml0eSBvZiBzbWFsbC1USFAgZm9s aW9zLCB3ZQo+IGRvbid0IGhhdmUgcGVyZm9ybWFuY2UKPiBpbXByb3ZlbWVudCwgYW5kIHByb2Jh Ymx5IHJlZ3Jlc3Npb24gaW5zdGVhZC4gVGhpcyBpcyByZWFsbHkgdHJ1ZSBvbgo+IHJlYWwgd29y a2xvYWRzISEKPiAKPiBTbyB0aGF0IGlzIHdoeSB3ZSByZWFsbHkgbG92ZSBhIHBlci1WTUEgaGlu dCB0byBlbmFibGUgc21hbGwtVEhQIGJ1dAo+IG9idmlvdXNseSB5b3UKPiBoYXZlIGFscmVhZHkg c3VwcG9ydGVkIGl0IG5vdyBieQo+IG1tOiB0aHA6IEludHJvZHVjZSBwZXItc2l6ZSB0aHAgc3lz ZnMgaW50ZXJmYWNlCj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvbGludXgtbW0vMjAyMzExMjIx NjI5NTAuMzg1NDg5Ny00LXJ5YW4ucm9iZXJ0c0Bhcm0uY29tLwo+IAo+IHdlIGNhbiB1c2UgTUFE VklTRSByYXRoZXIgdGhhbiBBTFdBWVMgYW5kIHNldCBmaXhlZCBzaXplIGxpa2UgNjRLQiwgc28g dXNlcnNwYWNlCj4gY2FuIHNldCB0aGUgVk1BIGZsYWcgd2hlbiBpdCBpcyBxdWl0ZSBzdXJlIHRo aXMgVk1BIGlzIHdvcmtpbmcgd2l0aAo+IHRoZSBhbGlnbm1lbnQKPiBvZiA2NEtCPwoKWWVzLCB0 aGF0IGFsbCBleGlzdHMgaW4gdGhlIHNlcmllcyB0b2RheS4gV2UgaGF2ZSBhbHNvIGRpc2N1c3Nl ZCB0aGUgcG9zc2liaWxpdHkKb2YgYWRkaW5nIGEgbmV3IG1hZHZpc2VfcHJvY2VzcygpIGNhbGwg dGhhdCB3b3VsZCB0YWtlIHRoZSBzZXQgb2YgVEhQIHNpemVzIHRoYXQKc2hvdWxkIGJlIGNvbnNp ZGVyZWQuIFRoZW4geW91IGNhbiBzZXQgZGlmZmVyZW50IFZNQXMgdG8gdXNlIGRpZmZlcmVudCBz aXplczsKdGhlIHBsYW4gd2FzIHRvIGxheWVyIHRoYXQgb24gdG9wIGlmL3doZW4gYSB3b3JrbG9h ZCB3YXMgaWRlbnRpZmllZC4gU291bmRzIGxpa2UKeW91IG1pZ2h0IGJlIGFibGUgdG8gaGVscCB0 aGVyZT8KCj4gCj4+Cj4+IFJlZ2FyZGxlc3MsIGl0IHdvdWxkIGJlIGdvb2QgdG8gbW92ZSB0aGlz IGNvbnZlcnNhdGlvbiB0byB0aGUgc21hbGwtc2l6ZWQgVEhQCj4+IHBhdGNoIHNlcmllcyBzaW5j ZSB0aGlzIGlzIGFsbCBpbmRlcGVuZGVudCBvZiBjb250cHRlIG1hcHBpbmdzLgo+Pgo+Pj4KPj4+ Pgo+Pj4+Pgo+Pj4+PiBTaW5jZSB3ZSBhbHdheXMgaG9sZCBwdGwgdG8gc2V0IG9yIGRyb3AgQ09O VFBURSBiaXRzLCBzZXQvZHJvcCBpcwo+Pj4+PiBzdGlsbCBhdG9taWMgaW4gYQo+Pj4+PiBzcGlu bG9jayBhcmVhLgo+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+Pj4KPj4+Pj4+Pj4gQnV0IHRoYXQgY2FuIGJl IGFkZGVkIG9uIHRvcCwgYW5kIEknbGwgaGFwcGlseSBkbyB0aGF0Lgo+Pj4+Pj4+Pgo+Pj4+Pj4+ PiAtLQo+Pj4+Pj4+PiBDaGVlcnMsCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IERhdmlkIC8gZGhpbGRlbmIK Pj4+Pj4+Pgo+Pj4+Pgo+Pj4KPiAKPiBUaGFua3MKPiBCYXJyeQoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBs aXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5m cmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB5E5C4167B for ; Tue, 28 Nov 2023 09:14:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D7286B0291; Tue, 28 Nov 2023 04:14:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 387C56B02A5; Tue, 28 Nov 2023 04:14:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24FFA6B02AD; Tue, 28 Nov 2023 04:14:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1295F6B0291 for ; Tue, 28 Nov 2023 04:14:28 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C9B6880131 for ; Tue, 28 Nov 2023 09:14:27 +0000 (UTC) X-FDA: 81506802174.14.5E7849D Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf16.hostedemail.com (Postfix) with ESMTP id EFA3D180014 for ; Tue, 28 Nov 2023 09:14:24 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf16.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701162865; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OP3ag60LowcdWpDh5If+yaV6nKcRij37x1mEkiYiuMo=; b=1JecTOR169EBUaKfO1QE1eJtCLvOjPQooRUvKrTh8raHZm7uuR8lwT61Fithm+3KOmu6ZB /P7qk08cVgQTFR+57Cp43VDoSQ7Kat07iwkj+DabI/qRscSxrxLlwXBvsqLNreCac68JRs p6vrWpkkq0Ys7ERJERwKJnhkXvyepoA= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf16.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701162865; a=rsa-sha256; cv=none; b=pzTjaol0i+C8LYd2Sb9ZmJlRWkVqcq4nz6qj1G4O69u4SFoO5rSBREMatS50qu2HwSlcXg 3LNEiNyS0b5uEle6r6U8pPtS4bh59uC94+CZFW/qQDwwjeqTLlpc8QJpRWjq8GfJrP4bta UxUOgm4702bpNIE1F3vTXRpKNicy3nE= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 57CBBC15; Tue, 28 Nov 2023 01:15:11 -0800 (PST) Received: from [10.57.73.192] (unknown [10.57.73.192]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 33A823F73F; Tue, 28 Nov 2023 01:14:19 -0800 (PST) Message-ID: <7c4c8ab2-8eb2-472d-ad8d-9d6c20b2191c@arm.com> Date: Tue, 28 Nov 2023 09:14:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 01/14] mm: Batch-copy PTE ranges during fork() Content-Language: en-GB To: Barry Song <21cnbao@gmail.com> Cc: david@redhat.com, akpm@linux-foundation.org, andreyknvl@gmail.com, anshuman.khandual@arm.com, ardb@kernel.org, catalin.marinas@arm.com, dvyukov@google.com, glider@google.com, james.morse@arm.com, jhubbard@nvidia.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mark.rutland@arm.com, maz@kernel.org, oliver.upton@linux.dev, ryabinin.a.a@gmail.com, suzuki.poulose@arm.com, vincenzo.frascino@arm.com, wangkefeng.wang@huawei.com, will@kernel.org, willy@infradead.org, yuzenghui@huawei.com, yuzhao@google.com, ziy@nvidia.com References: <271f1e98-6217-4b40-bae0-0ac9fe5851cb@redhat.com> <20231127084217.13110-1-v-songbaohua@oppo.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: EFA3D180014 X-Stat-Signature: ii8d9461bdy3w7eyuk35yyd6j1dzodoj X-Rspam-User: X-HE-Tag: 1701162864-416307 X-HE-Meta: U2FsdGVkX1+lfX9aNG8AyUyb4nET02o+/dtkWK4HEAIEHEaF1b3TMRgUfN01JgH0RLpqbCv9nAe0PsjF+Q/BBBFLs/cuOf3/LSPwjdYGWoDA1IX7qKoXIPdAg+JlRUbQoXqA9GDMNRqE4JV48KHScUc9zRD38kR0LWgUsSxcUfBVSckakblNLt+FdH1YczOAZeDFBmRPFRyEtLCy38MKjkSnMR9wmqaZX1U2fqYAmLzkMqiyBSVkW84xoUrxSPu0Jxr7H3XbPpMJgCeK2eDDjLu52c7XA0zTykT6Jd3rJbO+UQJ6NTTFT0Gm310hcItzM51FuMIu37epWwEs99eQ5mb6wAAd7grwHrChBmbUvHIMOBvxJl16op9dd8wRNgRtoauImbxBUyn1xS+LWhEX92TuMtfnMzXFUNWdVz42GydoS4h/VwnOBf+o5D72msNFizBTnqgBdYKSaxY3uo1mvKOf0UFFc3qPo3GVI6+QliS084I5NtwMQTi4hSkpvgytoahdGVtf9XMBNGIFww9wusjYd/Tj5z1oydcsmRtGbVA3NcpEI8HtihWCmsL7Hb8W7CEzkMFK4HSiolTuuLYXjYF3x0eMBVr4CHbYD1bXvYR40aNdRo7OELqJh+G8wf4EOt27RfVV7mvgxkXH/vix4ydx+QprNVLqVk204ty6UprpwdqX67dafcg3Mv1h+QvVuvXzapDbFrTMxnhUljwRgAMPYbNHoQKkgBvEV+lST5P8K3nfVEzUS2hA02cd2l5t4v9Dt9bcVwr/FPBH3g1uyU81SDR2KJay7QrkRQqLwsTRDNMakbDfTc1fp6WlxH8CUPisUHt0vOi8ZWzI9s4ghML6B54lEcnGJ0KeyP6PkcqtczWA8syjXtpo6MxnqwardFFnUzvih0K1R2MvTSr3BUDNn0NFA9ifWc1ZknqeCQgiP6ioOlOOcIbKhGxI1rE6DvsVpRFcJ1KShvc7Ind YYZfxOdh 8z2MycwcoBG8sr54Tbm8ORhaollR2kYCr3KnpFr0tOerANkvCkyoQB/yorQ+G1wcAuYvabIvWrBO20eIX9i7Qj60PRk3+ukq/nmKA95RWhRbKkdjD8B+C0H/Ow16OQqOeXAMpJs3usTcvXmEu2uNRTQ9dXt8CFzF9eVUy0xSIZD4+1kyOKY/7TR2Tgpu19/wo0nD9nL2T4E8xrLUmC0ssSQyL9E5aZtpw/7LakRf0NrHOOfWTx9Y0wqRjLxEQvCNOUjN9A0/ZntCBN+w+uArXG7uXVyhJZujlAvKvvECy99u2SY6y4iRZW+1EsvOHiWk6kUtjbhSSgeOnCqX1oz/b8B62vsmYhe9KLPCdjdTAne9v0y7UsCx/KrYGfzf/DkVBEQBNcnCwnMOVBuSbeJpcsjnXOw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 27/11/2023 20:34, Barry Song wrote: > On Tue, Nov 28, 2023 at 12:07 AM Ryan Roberts wrote: >> >> On 27/11/2023 10:28, Barry Song wrote: >>> On Mon, Nov 27, 2023 at 11:11 PM Ryan Roberts wrote: >>>> >>>> On 27/11/2023 09:59, Barry Song wrote: >>>>> On Mon, Nov 27, 2023 at 10:35 PM Ryan Roberts wrote: >>>>>> >>>>>> On 27/11/2023 08:42, Barry Song wrote: >>>>>>>>> + for (i = 0; i < nr; i++, page++) { >>>>>>>>> + if (anon) { >>>>>>>>> + /* >>>>>>>>> + * If this page may have been pinned by the >>>>>>>>> + * parent process, copy the page immediately for >>>>>>>>> + * the child so that we'll always guarantee the >>>>>>>>> + * pinned page won't be randomly replaced in the >>>>>>>>> + * future. >>>>>>>>> + */ >>>>>>>>> + if (unlikely(page_try_dup_anon_rmap( >>>>>>>>> + page, false, src_vma))) { >>>>>>>>> + if (i != 0) >>>>>>>>> + break; >>>>>>>>> + /* Page may be pinned, we have to copy. */ >>>>>>>>> + return copy_present_page( >>>>>>>>> + dst_vma, src_vma, dst_pte, >>>>>>>>> + src_pte, addr, rss, prealloc, >>>>>>>>> + page); >>>>>>>>> + } >>>>>>>>> + rss[MM_ANONPAGES]++; >>>>>>>>> + VM_BUG_ON(PageAnonExclusive(page)); >>>>>>>>> + } else { >>>>>>>>> + page_dup_file_rmap(page, false); >>>>>>>>> + rss[mm_counter_file(page)]++; >>>>>>>>> + } >>>>>>>>> } >>>>>>>>> - rss[MM_ANONPAGES]++; >>>>>>>>> - } else if (page) { >>>>>>>>> - folio_get(folio); >>>>>>>>> - page_dup_file_rmap(page, false); >>>>>>>>> - rss[mm_counter_file(page)]++; >>>>>>>>> + >>>>>>>>> + nr = i; >>>>>>>>> + folio_ref_add(folio, nr); >>>>>>>> >>>>>>>> You're changing the order of mapcount vs. refcount increment. Don't. >>>>>>>> Make sure your refcount >= mapcount. >>>>>>>> >>>>>>>> You can do that easily by doing the folio_ref_add(folio, nr) first and >>>>>>>> then decrementing in case of error accordingly. Errors due to pinned >>>>>>>> pages are the corner case. >>>>>>>> >>>>>>>> I'll note that it will make a lot of sense to have batch variants of >>>>>>>> page_try_dup_anon_rmap() and page_dup_file_rmap(). >>>>>>>> >>>>>>> >>>>>>> i still don't understand why it is not a entire map+1, but an increment >>>>>>> in each basepage. >>>>>> >>>>>> Because we are PTE-mapping the folio, we have to account each individual page. >>>>>> If we accounted the entire folio, where would we unaccount it? Each page can be >>>>>> unmapped individually (e.g. munmap() part of the folio) so need to account each >>>>>> page. When PMD mapping, the whole thing is either mapped or unmapped, and its >>>>>> atomic, so we can account the entire thing. >>>>> >>>>> Hi Ryan, >>>>> >>>>> There is no problem. for example, a large folio is entirely mapped in >>>>> process A with CONPTE, >>>>> and only page2 is mapped in process B. >>>>> then we will have >>>>> >>>>> entire_map = 0 >>>>> page0.map = -1 >>>>> page1.map = -1 >>>>> page2.map = 0 >>>>> page3.map = -1 >>>>> .... >>>>> >>>>>> >>>>>>> >>>>>>> as long as it is a CONTPTE large folio, there is no much difference with >>>>>>> PMD-mapped large folio. it has all the chance to be DoubleMap and need >>>>>>> split. >>>>>>> >>>>>>> When A and B share a CONTPTE large folio, we do madvise(DONTNEED) or any >>>>>>> similar things on a part of the large folio in process A, >>>>>>> >>>>>>> this large folio will have partially mapped subpage in A (all CONTPE bits >>>>>>> in all subpages need to be removed though we only unmap a part of the >>>>>>> large folioas HW requires consistent CONTPTEs); and it has entire map in >>>>>>> process B(all PTEs are still CONPTES in process B). >>>>>>> >>>>>>> isn't it more sensible for this large folios to have entire_map = 0(for >>>>>>> process B), and subpages which are still mapped in process A has map_count >>>>>>> =0? (start from -1). >>>>>>> >>>>>>>> Especially, the batch variant of page_try_dup_anon_rmap() would only >>>>>>>> check once if the folio maybe pinned, and in that case, you can simply >>>>>>>> drop all references again. So you either have all or no ptes to process, >>>>>>>> which makes that code easier. >>>>>> >>>>>> I'm afraid this doesn't make sense to me. Perhaps I've misunderstood. But >>>>>> fundamentally you can only use entire_mapcount if its only possible to map and >>>>>> unmap the whole folio atomically. >>>>> >>>>> >>>>> >>>>> My point is that CONTPEs should either all-set in all 16 PTEs or all are dropped >>>>> in 16 PTEs. if all PTEs have CONT, it is entirely mapped; otherwise, >>>>> it is partially >>>>> mapped. if a large folio is mapped in one processes with all CONTPTEs >>>>> and meanwhile in another process with partial mapping(w/o CONTPTE), it is >>>>> DoubleMapped. >>>> >>>> There are 2 problems with your proposal, as I see it; >>>> >>>> 1) the core-mm is not enlightened for CONTPTE mappings. As far as it is >>>> concerned, its just mapping a bunch of PTEs. So it has no hook to inc/dec >>>> entire_mapcount. The arch code is opportunistically and *transparently* managing >>>> the CONT_PTE bit. >>>> >>>> 2) There is nothing to say a folio isn't *bigger* than the contpte block; it may >>>> be 128K and be mapped with 2 contpte blocks. Or even a PTE-mapped THP (2M) and >>>> be mapped with 32 contpte blocks. So you can't say it is entirely mapped >>>> unless/until ALL of those blocks are set up. And then of course each block could >>>> be unmapped unatomically. >>>> >>>> For the PMD case there are actually 2 properties that allow using the >>>> entire_mapcount optimization; It's atomically mapped/unmapped through the PMD >>>> and we know that the folio is exactly PMD sized (since it must be at least PMD >>>> sized to be able to map it with the PMD, and we don't allocate THPs any bigger >>>> than PMD size). So one PMD map or unmap operation corresponds to exactly one >>>> *entire* map or unmap. That is not true when we are PTE mapping. >>> >>> well. Thanks for clarification. based on the above description, i agree the >>> current code might make more sense by always using mapcount in subpage. >>> >>> I gave my proposals as I thought we were always CONTPTE size for small-THP >>> then we could drop the loop to iterate 16 times rmap. if we do it >>> entirely, we only >>> need to do dup rmap once for all 16 PTEs by increasing entire_map. >> >> Well its always good to have the discussion - so thanks for the ideas. I think >> there is a bigger question lurking here; should we be exposing the concept of >> contpte mappings to the core-mm rather than burying it in the arm64 arch code? >> I'm confident that would be a huge amount of effort and the end result would be >> similar performace to what this approach gives. One potential benefit of letting >> core-mm control it is that it would also give control to core-mm over the >> granularity of access/dirty reporting (my approach implicitly ties it to the >> folio). Having sub-folio access tracking _could_ potentially help with future >> work to make THP size selection automatic, but we are not there yet, and I think >> there are other (simpler) ways to achieve the same thing. So my view is that >> _not_ exposing it to core-mm is the right way for now. > > Hi Ryan, > > We(OPPO) started a similar project like you even before folio was imported to > mainline, we have deployed the dynamic hugepage(that is how we name it) > on millions of mobile phones on real products and kernels before 5.16, making > a huge success on performance improvement. for example, you may > find the out-of-tree 5.15 source code here Oh wow, thanks for reaching out and explaining this - I have to admit I feel embarrassed that I clearly didn't do enough research on the prior art because I wasn't aware of your work. So sorry about that. I sensed that you had a different model for how this should work vs what I've implemented and now I understand why :). I'll review your stuff and I'm sure I'll have questions. I'm sure each solution has pros and cons. > > https://github.com/OnePlusOSS/android_kernel_oneplus_sm8550/tree/oneplus/sm8550_u_14.0.0_oneplus11 > > Our modification might not be so clean and has lots of workarounds > just for the stability of products > > We mainly have > > 1. https://github.com/OnePlusOSS/android_kernel_oneplus_sm8550/blob/oneplus/sm8550_u_14.0.0_oneplus11/mm/cont_pte_hugepage.c > > some CONTPTE helpers > > 2.https://github.com/OnePlusOSS/android_kernel_oneplus_sm8550/blob/oneplus/sm8550_u_14.0.0_oneplus11/include/linux/mm.h > > some Dynamic Hugepage APIs > > 3. https://github.com/OnePlusOSS/android_kernel_oneplus_sm8550/blob/oneplus/sm8550_u_14.0.0_oneplus11/mm/memory.c > > modified all page faults to support > (1). allocation of hugepage of 64KB in do_anon_page My Small-Sized THP patch set is handling the equivalent of this. > (2). CoW hugepage in do_wp_page This isn't handled yet in my patch set; the original RFC implemented it but I removed it in order to strip back to the essential complexity for the initial submission. DavidH has been working on a precise shared vs exclusive map tracking mechanism - if that goes in, it will make CoWing large folios simpler. Out of interest, what workloads benefit most from this? > (3). copy CONPTEs in copy_pte_range As discussed this is done as part of the contpte patch set, but its not just a simple copy; the arch code will notice and set the CONT_PTE bit as needed. > (4). allocate and swap-in Hugepage as a whole in do_swap_page This is going to be a problem but I haven't even looked at this properly yet. The advice so far has been to continue to swap-in small pages only, but improve khugepaged to collapse to small-sized THP. I'll take a look at your code to understand how you did this. > > 4. https://github.com/OnePlusOSS/android_kernel_oneplus_sm8550/blob/oneplus/sm8550_u_14.0.0_oneplus11/mm/vmscan.c > https://github.com/OnePlusOSS/android_kernel_oneplus_sm8550/blob/oneplus/sm8550_u_14.0.0_oneplus11/mm/rmap.c > > reclaim hugepage as a whole and LRU optimization for 64KB dynamic hugepage. I think this is all naturally handled by the folio code that exists in modern kernels? > > So we are 100% interested in your patchset and hope it can find a way > to land on the > mainline, thus decreasing all the cost we have to maintain out-of-tree > code from a > kernel to another kernel version which we have done on a couple of > kernel versions > before 5.16. Firmly, we are 100% supportive of large anon folios > things you are leading. That's great to hear! Of course Reviewed-By's and Tested-By's will all help move it closer :). If you had any ability to do any A/B performance testing, it would be very interesting to see how this stacks up against your solution - if there are gaps it would be good to know where and develop a plan to plug the gap. > > A big pain was we found lots of races especially on CONTPTE unfolding > and especially a part > of basepages ran away from the 16 CONPTEs group since userspace is > always working > on basepages, having no idea of small-THP. We ran our code on millions of > real phones, and now we have got them fixed (or maybe "can't reproduce"), > no outstanding issue. I'm going to be brave and say that my solution shouldn't suffer from these problems; but of course the proof is only in the testing. I did a lot of work with our architecture group and micro architects to determine exactly what is and isn't safe; We even tightened the Arm ARM spec very subtlely to allow the optimization in patch 13 (see the commit log for details). Of course this has all been checked with partners and we are confident that all existing implementations conform to the modified wording. > > Particularly for the rmap issue we are discussing, our out-of-tree is > using the entire_map for > CONTPTE in the way I sent to you. But I guess we can learn from you to decouple > CONTPTE from mm-core. > > We are doing this in mm/memory.c > > copy_present_cont_pte(struct vm_area_struct *dst_vma, struct > vm_area_struct *src_vma, > pte_t *dst_pte, pte_t *src_pte, unsigned long addr, int *rss, > struct page **prealloc) > { > struct mm_struct *src_mm = src_vma->vm_mm; > unsigned long vm_flags = src_vma->vm_flags; > pte_t pte = *src_pte; > struct page *page; > > page = vm_normal_page(src_vma, addr, pte); > ... > > get_page(page); > page_dup_rmap(page, true); // an entire dup_rmap as you can > see............. > rss[mm_counter(page)] += HPAGE_CONT_PTE_NR; > } > > and we have a split in mm/cont_pte_hugepage.c to handle partially unmap, > > static void __split_huge_cont_pte_locked(struct vm_area_struct *vma, pte_t *pte, > unsigned long haddr, bool freeze) > { > ... > if (compound_mapcount(head) > 1 && !TestSetPageDoubleMap(head)) { > for (i = 0; i < HPAGE_CONT_PTE_NR; i++) > atomic_inc(&head[i]._mapcount); > atomic_long_inc(&cont_pte_double_map_count); > } > > > if (atomic_add_negative(-1, compound_mapcount_ptr(head))) { > ... > } > > I am not selling our solution any more, but just showing you some differences we > have :-) OK, I understand what you were saying now. I'm currently struggling to see how this could fit into my model. Do you have any workloads and numbers on perf improvement of using entire_mapcount? > >> >>> >>> BTW, I have concerns that a variable small-THP size will really work >>> as userspace >>> is probably friendly to only one fixed size. for example, userspace >>> heap management >>> might be optimized to a size for freeing memory to the kernel. it is >>> very difficult >>> for the heap to adapt to various sizes at the same time. frequent unmap/free >>> size not equal with, and particularly smaller than small-THP size will >>> defeat all >>> efforts to use small-THP. >> >> I'll admit to not knowing a huge amount about user space allocators. But I will >> say that as currently defined, the small-sized THP interface to user space >> allows a sysadmin to specifically enable the set of sizes that they want; so a >> single size can be enabled. I'm diliberately punting that decision away from the >> kernel for now. > > Basically, userspace heap library has a PAGESIZE setting and allows users > to allocate/free all kinds of small objects such as 16,32,64,128,256,512 etc. > The default size is for sure equal to the basepage SIZE. once some objects are > freed by free() and libc get a free "page", userspace heap libraries might free > the PAGESIZE page to kernel by things like MADV_DONTNEED, then zap_pte_range(). > it is quite similar with kernel slab. > > so imagine we have small-THP now, but userspace libraries have *NO* > idea at all, so it can frequently cause unfolding. > >> >> FWIW, My experience with the Speedometer/JavaScript use case is that performance >> is a little bit better when enabling 64+32+16K vs just 64K THP. >> >> Functionally, it will not matter if the allocator is not enlightened for the THP >> size; it can continue to free, and if a partial folio is unmapped it is put on >> the deferred split list, then under memory pressure it is split and the unused >> pages are reclaimed. I guess this is the bit you are concerned about having a >> performance impact? > > right. If this is happening on the majority of small-THP folios, we > don't have performance > improvement, and probably regression instead. This is really true on > real workloads!! > > So that is why we really love a per-VMA hint to enable small-THP but > obviously you > have already supported it now by > mm: thp: Introduce per-size thp sysfs interface > https://lore.kernel.org/linux-mm/20231122162950.3854897-4-ryan.roberts@arm.com/ > > we can use MADVISE rather than ALWAYS and set fixed size like 64KB, so userspace > can set the VMA flag when it is quite sure this VMA is working with > the alignment > of 64KB? Yes, that all exists in the series today. We have also discussed the possibility of adding a new madvise_process() call that would take the set of THP sizes that should be considered. Then you can set different VMAs to use different sizes; the plan was to layer that on top if/when a workload was identified. Sounds like you might be able to help there? > >> >> Regardless, it would be good to move this conversation to the small-sized THP >> patch series since this is all independent of contpte mappings. >> >>> >>>> >>>>> >>>>> Since we always hold ptl to set or drop CONTPTE bits, set/drop is >>>>> still atomic in a >>>>> spinlock area. >>>>> >>>>>> >>>>>>>> >>>>>>>> But that can be added on top, and I'll happily do that. >>>>>>>> >>>>>>>> -- >>>>>>>> Cheers, >>>>>>>> >>>>>>>> David / dhildenb >>>>>>> >>>>> >>> > > Thanks > Barry