Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201102091428.GK31092@shao2-debian>
In-Reply-To: <20201102091428.GK31092@shao2-debian>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed, 4 Nov 2020 10:29:59 -0800
Message-ID: <CAHk-=wiRnRsS4CqLypK533G2Ho=NVTt_s-e9KXZ=b0ptOSB15A@mail.gmail.com>
Subject: Re: [mm/gup] a308c71bf1: stress-ng.vm-splice.ops_per_sec -95.6% regression
To:     kernel test robot <rong.a.chen@intel.com>,
        Jann Horn <jannh@google.com>
Cc:     Peter Xu <peterx@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
        lkp@lists.01.org, kernel test robot <lkp@intel.com>,
        "Huang, Ying" <ying.huang@intel.com>,
        Feng Tang <feng.tang@intel.com>, zhengjun.xing@intel.com
Content-Type: multipart/mixed; boundary="000000000000bac91505b34c2b78"
Precedence: bulk

--000000000000bac91505b34c2b78
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 2, 2020 at 1:15 AM kernel test robot <rong.a.chen@intel.com> wrote:
>
> Greeting,
>
> FYI, we noticed a -95.6% regression of stress-ng.vm-splice.ops_per_sec due to commit:
>
> commit: a308c71bf1e6e19cc2e4ced31853ee0fc7cb439a ("mm/gup: Remove enfornced COW mechanism")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

Note that this is just the reverse of the previous 2000% improvement
reported by the test robot here:

    https://lore.kernel.org/lkml/20200611040453.GK12456@shao2-debian/

and the explanation seems to remain the same:

    https://lore.kernel.org/lkml/CAG48ez1v1b4X5LgFya6nvi33-TWwqna_dc5jGFVosqQhdn_Nkg@mail.gmail.com/

IOW, this is testing a special case (zero page lookup) that the "force
COW" patches happened to turn into a regular case (COW creating a
regular page from the zero page).

The question is whether we should care about the zero page for gup_fast lookup.

If we do care, then the proper fix is likely simply to allow the zero
page in fast-gup, the same way we already do in slow-gup.

ENTIRELY UNTESTED PATCH ATTACHED.

Rong - mind testing this? I don't think the zero-page _should_ be
something that real loads care about, but hey, maybe people do want to
do things like splice zeroes very efficiently..

And note the "untested" part of the patch. It _looks_ fairly obvious,
but maybe I'm missing something.

            Linus

--000000000000bac91505b34c2b78
Content-Type: application/octet-stream; name=patch
Content-Disposition: attachment; filename=patch
Content-Transfer-Encoding: base64
Content-ID: <f_kh3qhmzd0>
X-Attachment-Id: f_kh3qhmzd0

IG1tL2d1cC5jIHwgNyArKysrKy0tCiAxIGZpbGUgY2hhbmdlZCwgNSBpbnNlcnRpb25zKCspLCAy
IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL21tL2d1cC5jIGIvbW0vZ3VwLmMKaW5kZXggMTAy
ODc3ZWQ3N2E0Li44OTY2ZDNjODllNWQgMTAwNjQ0Ci0tLSBhL21tL2d1cC5jCisrKyBiL21tL2d1
cC5jCkBAIC0yMTgyLDggKzIxODIsMTEgQEAgc3RhdGljIGludCBndXBfcHRlX3JhbmdlKHBtZF90
IHBtZCwgdW5zaWduZWQgbG9uZyBhZGRyLCB1bnNpZ25lZCBsb25nIGVuZCwKIAkJCQl1bmRvX2Rl
dl9wYWdlbWFwKG5yLCBucl9zdGFydCwgZmxhZ3MsIHBhZ2VzKTsKIAkJCQlnb3RvIHB0ZV91bm1h
cDsKIAkJCX0KLQkJfSBlbHNlIGlmIChwdGVfc3BlY2lhbChwdGUpKQotCQkJZ290byBwdGVfdW5t
YXA7CisJCX0gZWxzZSBpZiAocHRlX3NwZWNpYWwocHRlKSkgeworCQkJaWYgKCFpc196ZXJvX3Bm
bihwdGVfcGZuKHB0ZSkpKQorCQkJCWdvdG8gcHRlX3VubWFwOworCQkJLyogV2UnbGwgYWxsb3cg
dGhlIHplcm8gcGFnZSAtIGxpa2UgZm9sbG93X3BhZ2VfcHRlKCkgZG9lcyAqLworCQl9CiAKIAkJ
Vk1fQlVHX09OKCFwZm5fdmFsaWQocHRlX3BmbihwdGUpKSk7CiAJCXBhZ2UgPSBwdGVfcGFnZShw
dGUpOwo=
--000000000000bac91505b34c2b78--