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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 737EEC433B4 for ; Thu, 8 Apr 2021 18:45:00 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 03BA1610FC for ; Thu, 8 Apr 2021 18:44:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 03BA1610FC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=containers-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B0F804183F; Thu, 8 Apr 2021 18:44:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBApReMZoj1k; Thu, 8 Apr 2021 18:44:58 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp4.osuosl.org (Postfix) with ESMTP id 648484183B; Thu, 8 Apr 2021 18:44:58 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 39597C000C; Thu, 8 Apr 2021 18:44:58 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 040C3C000A for ; Thu, 8 Apr 2021 18:44:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id DDE534183C for ; Thu, 8 Apr 2021 18:44:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F70SCTpRa_I8 for ; Thu, 8 Apr 2021 18:44:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by smtp4.osuosl.org (Postfix) with ESMTPS id 8D9A84183B for ; Thu, 8 Apr 2021 18:44:55 +0000 (UTC) Received: from in02.mta.xmission.com ([166.70.13.52]) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lUZe5-00Ejb5-PM; Thu, 08 Apr 2021 12:44:50 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lUZe4-00A0nq-5p; Thu, 08 Apr 2021 12:44:49 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds References: <7abe5ab608c61fc2363ba458bea21cf9a4a64588.1617814298.git.gladkov.alexey@gmail.com> <20210408083026.GE1696@xsang-OptiPlex-9020> Date: Thu, 08 Apr 2021 13:44:43 -0500 In-Reply-To: (Linus Torvalds's message of "Thu, 8 Apr 2021 09:22:40 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1lUZe4-00A0nq-5p; ; ; mid=; ; ; hst=in02.mta.xmission.com; ; ; ip=68.227.160.95; ; ; frm=ebiederm@xmission.com; ; ; spf=neutral X-XM-AID: U2FsdGVkX19JLUsOtBvU+Hb1U0UwhyIZDve8LzlJSks= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: 08ed4efad6: stress-ng.sigsegv.ops_per_sec -41.9% regression X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Cc: Jens Axboe , Feng Tang , 0day robot , Kernel Hardening , Linux Containers , Jann Horn , LKML , Oleg Nesterov , Linux-MM , lkp@lists.01.org, kernel test robot , "Huang, Ying" , Andrew Morton , zhengjun.xing@intel.com, Alexey Gladkov , Kees Cook X-BeenThere: containers@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux Containers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: containers-bounces@lists.linux-foundation.org Sender: "Containers" TGludXMgVG9ydmFsZHMgPHRvcnZhbGRzQGxpbnV4LWZvdW5kYXRpb24ub3JnPiB3cml0ZXM6Cgo+ IE9uIFRodSwgQXByIDgsIDIwMjEgYXQgMTozMiBBTSBrZXJuZWwgdGVzdCByb2JvdCA8b2xpdmVy LnNhbmdAaW50ZWwuY29tPiB3cm90ZToKPj4KPj4gRllJLCB3ZSBub3RpY2VkIGEgLTQxLjklIHJl Z3Jlc3Npb24gb2Ygc3RyZXNzLW5nLnNpZ3NlZ3Yub3BzX3Blcl9zZWMgZHVlIHRvIGNvbW1pdAo+ PiAwOGVkNGVmYWQ2ODQgKCJbUEFUQ0ggdjEwIDYvOV0gUmVpbXBsZW1lbnQgUkxJTUlUX1NJR1BF TkRJTkcgb24gdG9wIG9mIHVjb3VudHMiKQo+Cj4gT3VjaC4KCldlIHdlcmUgY2F1dGlvdXNseSBv cHRpbWlzdGljIHdoZW4gbm8gdGVzdCBwcm9ibGVtcyBzaG93ZWQgdXAgZnJvbQp0aGUgbGFzdCBw b3N0aW5nIHRoYXQgdGhlcmUgd2FzIG5vdGhpbmcgdG8gbG9vayBhdCBoZXJlLgoKVW5mb3J0dW5h dGVseSBpdCBsb29rcyBsaWtlIHRoZSBib3RzIGp1c3QgbWlzc2VkIHRoZSBsYXN0IHBvc3Rpbmcu IAoKU28gaXQgc2VlbXMgd2UgYXJlIGZpbmFsbHkgcHJldHR5IG11Y2ggYXQgY29ycmVjdCBjb2Rl IGluIG5lZWQKb2YgcGVyZm9ybWFuY2UgdHVuaW5nLgoKPiBJICp0aGluayogdGhpcyB0ZXN0IG1h eSBiZSB0ZXN0aW5nICJzZW5kIHNvIG1hbnkgc2lnbmFscyB0aGF0IGl0Cj4gdHJpZ2dlcnMgdGhl IHNpZ25hbCBxdWV1ZSBvdmVyZmxvdyBjYXNlIi4KPgo+IEFuZCBJICp0aGluayogdGhhdCB0aGUg cGVyZm9ybWFuY2UgZGVncmFkYXRpb24gbWF5IGJlIGR1ZSB0byBsb3RzIG9mCj4gdW5uZWNlc3Nh cnkgYWxsb2NhdGlvbnMsIGJlY2F1c2UgaXR5IGxvb2tzIGxpa2UgdGhhdCBjb21taXQgY2hhbmdl cwo+IF9fc2lncXVldWVfYWxsb2MoKSB0byBkbwo+Cj4gICAgICAgICBzdHJ1Y3Qgc2lncXVldWUg KnEgPSBrbWVtX2NhY2hlX2FsbG9jKHNpZ3F1ZXVlX2NhY2hlcCwgZmxhZ3MpOwo+Cj4gKmJlZm9y ZSogY2hlY2tpbmcgdGhlIHNpZ25hbCBsaW1pdCwgYW5kIHRoZW4gaWYgdGhlIHNpZ25hbCBsaW1p dCB3YXMKPiBleGNlZWRlZCwgaXQgd2lsbCBqdXN0IGJlIGZyZWUnZCBpbnN0ZWFkLgo+Cj4gVGhl IG9sZCBjb2RlIHdvdWxkIGNoZWNrIHRoZSBzaWduYWwgY291bnQgYWdhaW5zdCBSTElNSVRfU0lH UEVORElORwo+ICpmaXJzdCosIGFuZCBpZiB0aGVyZSB3ZXJlIG0gb3JlIHBlbmRpbmcgc2lnbmFs cyB0aGVuIGl0IHdvdWxkbid0IGRvCj4gYW55dGhpbmcgYXQgYWxsIChpbmNsdWRpbmcgbm90IGlu Y3JlbWVudGluZyB0aGF0IGV4cGVuc2l2ZSBhdG9taWMKPiBjb3VudCkuCgpUaGlzIGlzIGFuIGlu dGVyZXN0aW5nIHRlc3QgaW4gYSBsb3Qgb2Ygd2F5cyBhcyBpdCBpcyB0ZXN0aW5nIHRoZQpzeW5j aHJvbm91cyBzaWduYWwgZGVsaXZlcnkgcGF0aCBjYXVzZWQgYnkgYW4gZXhjZXB0aW9uLiAgVGhl IHRlc3QKaXMgZWl0aGVyIGV4ZWN1dGluZyAqcHRyID0gMCAod2hlcmUgcHRyIHBvaW50cyB0byBh IHJlYWQtb25seSBwYWdlKQpvciBpdCBleGVjdXRlcyBhbiB4ODYgaW5zdHJ1Y3Rpb24gdGhhdCBp cyBleGNlc3NpdmVseSBsb25nLgoKSSBoYXZlIGZvdW5kIHRoZSBjb2RlIGJ1dCBJIGhhdmVuJ3Qg ZmlndXJlZCBvdXQgaG93IGl0IGlzIGJlaW5nCmNhbGxlZCB5ZXQuICBUaGUgY29yZSBsb29wIGlz IGp1c3Q6Cglmb3IoOzspIHsKCQlzaWdhY3Rpb24oU0lHU0VHViwgJmFjdGlvbiwgTlVMTCk7CgkJ c2lnYWN0aW9uKFNJR0lMTCwgJmFjdGlvbiwgTlVMTCk7CgkJc2lnYWN0aW9uKFNJR0JVUywgJmFj dGlvbiwgTlVMTCk7CgoJCXJldCA9IHNpZ3NldGptcChqbXBfZW52LCAxKTsKCQlpZiAoZG9uZSgp KQogICAgICAgICAgICAgICAgCWJyZWFrOwoJCWlmIChyZXQpIHsKICAgICAgICAgICAgICAgIAkv KiB2ZXJpZnkgc2lnbmFsICovCiAgICAgICAgICAgICAgICB9IGVsc2UgewogICAgICAgICAgICAg ICAgCSpwdHIgPSAwOwogICAgICAgICAgICAgICAgfQoJfQoKQ29kZSBsaWtlIHRoYXQgZnVuZGFt ZW50YWxseSBjYW4gbm90IGJlIG11bHRpLXRocmVhZGVkLiAgU28gdGhlIG9ubHkgd2F5CnRoZSBz aWdwZW5kaW5nIGxpbWl0IGlzIGJlaW5nIGhpdCBpcyBpZiB0aGVyZSBhcmUgbW9yZSBwcm9jZXNz ZXMgcnVubmluZwp0aGF0IGNvZGUgc2ltdWx0YW5lb3VzbHkgdGhhbiB0aGUgc2l6ZSBvZiB0aGUg bGltaXQuCgpGdXJ0aGVyIGl0IGxvb2tzIGxpa2Ugc3RyZXNzLW5nIHB1c2hlcyBSTElNSVRfU0lH UEVORElORyBhcyBoaWdoIGFzIGl0CndpbGwgZ28gYmVmb3JlIHRoZSB0ZXN0IHN0YXJ0cy4KCgo+ IEFsc28sIHRoZSBvbGQgY29kZSB3YXMgdmVyeSBjYXJlZnVsIHRvIG9ubHkgZG8gdGhlICJnZXRf dXNlcigpIiBmb3IKPiB0aGUgKmZpcnN0KiBzaWduYWwgaXQgYWRkZWQgdG8gdGhlIHF1ZXVlLCBh bmQgZG8gdGhlICJwdXRfdXNlcigpIiBmb3IKPiB3aGVuIHJlbW92aW5nIHRoZSBsYXN0IHNpZ25h bC4gRXhhY3RseSBiZWNhdXNlIHRob3NlIGF0b21pY3MgYXJlIHZlcnkKPiBleHBlbnNpdmUuCj4K PiBUaGUgbmV3IGNvZGUganVzdCBkb2VzIGEgbG90IG9mIHRoZXNlIGF0b21pY3MgdW5jb25kaXRp b25hbGx5LgoKWWVzLiBUaGF0IHNlZW1zIGEgbGlrZWx5IGN1bHByaXQuCgo+IEkgZHVubm8uIFRo ZSBwcm9maWxlIGRhdGEgaW4gdGhlcmUgaXMgYSBiaXQgaGFyZCB0byByZWFkLCBidXQgdGhlcmUn cwo+IGEgbG90IG1vcmUgY2FjaGVlIG1pc3NlcywgYW5kIGEgKmxvdCogb2Ygbm9kZSBjcm9zc2Vy czoKPgo+PiAgICA1OTYxNTQ0ICAgICAgICAgICsxOTAuNCUgICAxNzMxNDM2MSAgICAgICAgcGVy Zi1zdGF0LmkuY2FjaGUtbWlzc2VzCj4+ICAgMjIxMDc0NjYgICAgICAgICAgKzExOS4yJSAgIDQ4 NDU3NjU2ICAgICAgICBwZXJmLXN0YXQuaS5jYWNoZS1yZWZlcmVuY2VzCj4+ICAgICAxNjMyOTIg xIUgIDMlICAgKzQ1ODIuMCUgICAgNzY0NTQxMCAgICAgICAgcGVyZi1zdGF0Lmkubm9kZS1sb2Fk LW1pc3Nlcwo+PiAgICAgMjI3Mzg4IMSFICAyJSAgICszNzA4LjglICAgIDg2NjA4MjQgICAgICAg IHBlcmYtc3RhdC5pLm5vZGUtbG9hZHMKPgo+IGFuZCAocHJvYmFibHkgYXMgYSByZXN1bHQpIGF2 ZXJhZ2UgaW5zdHJ1Y3Rpb24gY29zdHMgaGF2ZSBnb25lIHVwIGVub3Jtb3VzbHk6Cj4KPj4gICAg ICAgMy40NyAgICAgICAgICAgKzY2LjglICAgICAgIDUuNzkgICAgICAgIHBlcmYtc3RhdC5vdmVy YWxsLmNwaQo+PiAgICAgIDIyODQ5ICAgICAgICAgICAtNjUuNiUgICAgICAgNzg2NiAgICAgICAg cGVyZi1zdGF0Lm92ZXJhbGwuY3ljbGVzLWJldHdlZW4tY2FjaGUtbWlzc2VzCj4KPiBhbmQgaXQg ZG9lcyBzZWVtIHRvIGJlIGF0IGxlYXN0IHBhcnRseSBhYm91dCAicHV0X3Vjb3VudHMoKSI6Cj4K Pj4gICAgICAgMC4wMCAgICAgICAgICAgICs0LjUgICAgICAgIDQuNDYgICAgICAgIHBlcmYtcHJv ZmlsZS5jYWxsdHJhY2UuY3ljbGVzLXBwLnB1dF91Y291bnRzLl9fc2lncXVldWVfZnJlZS5nZXRf c2lnbmFsLmFyY2hfZG9fc2lnbmFsX29yX3Jlc3RhcnQuZXhpdF90b191c2VyX21vZGVfcHJlcGFy ZQo+Cj4gYW5kIGEgbG90IG9mICJnZXRfdWNvdW50cygpIi4KPgo+IEJ1dCBpdCBtYXkgYWxzbyBi ZSB0aGF0IHRoZSBuZXcgImdldCBzaWdwZW5kaW5nIiBpcyBqdXN0ICpzbyogbXVjaAo+IG1vcmUg ZXhwZW5zaXZlIHRoYW4gaXQgdXNlZCB0byBiZS4KClRoYXQgdG9vIGlzIHBvc3NpYmxlLgoKVGhh dCBub2RlLWxvYWQtbWlzc2VzIG51bWJlciBkb2VzIGxvb2sgbGlrZSBzb21ldGhpbmcgaXMgYm91 bmNpbmcgYmFjawphbmQgZm9ydGggYmV0d2VlbiB0aGUgbm9kZXMgYSBsb3QgbW9yZS4gIFNvIEkg c3VzcGVjdCBzdHJlc3MtbmcgaXMKcnVubmluZyBtdWx0aXBsZSBjb3BpZXMgb2YgdGhlIHNpZ3Nl Z3YgdGVzdCBpbiBkaWZmZXJlbnQgcHJvY2Vzc2VzIGF0Cm9uY2UuCgoKClRoYXQgcmVhbGx5IHN1 Z2dlc3RzIGNhY2hlIGxpbmUgcGluZyBwb25nIGZyb20gZ2V0X3Vjb3VudHMgYW5kCmluY3JlbWVu dGluZyBzaWdwZW5kaW5nLgoKSXQgc3VycHJpc2VzIG1lIHRoYXQgb2J0YWluaW5nIHRoZSBjYWNo ZSBsaW5lcyBleGNsdXNpdmVseSBpcwp0aGUgZG9taW5hbnQgY29zdCBvbiB0aGlzIGNvZGUgcGF0 aCBidXQgb2J0YWluaW5nIHR3byBjYWNoZSBsaW5lcwpleGNsdXNpdmVseSBpbnN0ZWFkIG9mIG9u ZSBjYWNoZSBjYWNoZSBsaW5lIGV4Y2x1c2l2ZWx5IGlzIGNvbnNpc3RlbnQKd2l0aCBhIGNhdXNp bmcgdGhlIGV4Y2VwdGlvbiBkZWxpdmVyeSB0byB0YWtlIG5lYXJseSB0d2ljZSBhcyBsb25nLgoK Rm9yIHRoZSBvcHRpbWl6YXRpb24gd2Ugb25seSBjYXJlIGFib3V0IHRoZSBsZWFmIGNvdW50IHNv IHdpdGggYSBsaXR0bGUKY2FyZSB3ZSBjYW4gcmVzdG9yZSB0aGUgb3B0aW1pemF0aW9uLiAgU28g dGhhdCBpcyBwcm9iYWJseSB0aGUgdGhpbmcKdG8gZG8gaGVyZS4gIFRoZSBmZXdlciBjaGFuZ2Vz IHRvIHdvcnJ5IGFib3V0IHRoZSBsZXNzIGxpa2VseSB0byBmaW5kCnN1cnByaXNlcy4KCgoKVGhh dCBzYWlkIGZvciB0aGlzIHNwZWNpZmljIGNhc2UgdGhlcmUgaXMgYSBsb3Qgb2YgcG90ZW50aWFs IHJvb20gZm9yCmltcHJvdmVtZW50LiAgQXMgdGhpcyBpcyBhIHBlciB0aHJlYWQgc2lnbmFsIHRo ZSBjb2RlIHVwZGF0ZSBzaWdwZW5kaW5nCmluIGNvbW1pdF9jcmVkIGFuZCBuZXZlciB3b3JyeSBh Ym91dCBuZWVkaW5nIHRvIHBpbiB0aGUgc3RydWN0CnVzZXJfc3RydWN0IG9yIHN0cnVjdCB1Y291 bnRzLiAgQXMgdGhpcyBpcyBhIHN5bmNocm9ub3VzIHNpZ25hbCB3ZSBjb3VsZApza2lwIHRoZSBz aWdwZW5kaW5nIGluY3JlbWVudCwgc2tpcCB0aGUgc2lnbmFsIHF1ZXVlIGVudGlyZWx5LCBhbmQK ZGVsaXZlciB0aGUgc2lnbmFsIHRvIHVzZXItc3BhY2UgaW1tZWRpYXRlbHkuICBUaGUgcmVtb3Zh bCBvZiBhbGwgY2FjaGUKcGluZyBwb25ncyBtaWdodCBtYWtlIGl0IHdvcnRoIGl0LgoKVGhlcmUg aXMgYWxzbyBUaG9tYXMgR2xlaXhuZXIncyByZWNlbnQgb3B0aW1pemF0aW9uIHRvIGNhY2hlIG9u ZQpzaWdxdWV1ZSBlbnRyeSBwZXIgdGFzayB0byBnaXZlIG1vcmUgcHJlZGljdGFibGUgYmVoYXZp b3IuICBUaGF0CndvdWxkIHJlbW92ZSB0aGUgY29zdCBvZiB0aGUgYWxsb2NhdGlvbi4KCkVyaWMK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ29udGFpbmVy cyBtYWlsaW5nIGxpc3QKQ29udGFpbmVyc0BsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZwpodHRw czovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb250YWluZXJz 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26AE9C433B4 for ; Thu, 8 Apr 2021 18:45:16 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 46AE1610CB for ; Thu, 8 Apr 2021 18:45:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 46AE1610CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-21181-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 7853 invoked by uid 550); 8 Apr 2021 18:45:07 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 7829 invoked from network); 8 Apr 2021 18:45:06 -0000 From: ebiederm@xmission.com (Eric W. Biederman) To: Linus Torvalds Cc: kernel test robot , Alexey Gladkov , 0day robot , LKML , lkp@lists.01.org, "Huang\, Ying" , Feng Tang , zhengjun.xing@intel.com, Kernel Hardening , Linux Containers , Linux-MM , Alexey Gladkov , Andrew Morton , Christian Brauner , Jann Horn , Jens Axboe , Kees Cook , Oleg Nesterov References: <7abe5ab608c61fc2363ba458bea21cf9a4a64588.1617814298.git.gladkov.alexey@gmail.com> <20210408083026.GE1696@xsang-OptiPlex-9020> Date: Thu, 08 Apr 2021 13:44:43 -0500 In-Reply-To: (Linus Torvalds's message of "Thu, 8 Apr 2021 09:22:40 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1lUZe4-00A0nq-5p;;;mid=;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19JLUsOtBvU+Hb1U0UwhyIZDve8LzlJSks= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: 08ed4efad6: stress-ng.sigsegv.ops_per_sec -41.9% regression X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Linus Torvalds writes: > On Thu, Apr 8, 2021 at 1:32 AM kernel test robot = wrote: >> >> FYI, we noticed a -41.9% regression of stress-ng.sigsegv.ops_per_sec due= to commit >> 08ed4efad684 ("[PATCH v10 6/9] Reimplement RLIMIT_SIGPENDING on top of u= counts") > > Ouch. We were cautiously optimistic when no test problems showed up from the last posting that there was nothing to look at here. Unfortunately it looks like the bots just missed the last posting.=20 So it seems we are finally pretty much at correct code in need of performance tuning. > I *think* this test may be testing "send so many signals that it > triggers the signal queue overflow case". > > And I *think* that the performance degradation may be due to lots of > unnecessary allocations, because ity looks like that commit changes > __sigqueue_alloc() to do > > struct sigqueue *q =3D kmem_cache_alloc(sigqueue_cachep, flags); > > *before* checking the signal limit, and then if the signal limit was > exceeded, it will just be free'd instead. > > The old code would check the signal count against RLIMIT_SIGPENDING > *first*, and if there were m ore pending signals then it wouldn't do > anything at all (including not incrementing that expensive atomic > count). This is an interesting test in a lot of ways as it is testing the synchronous signal delivery path caused by an exception. The test is either executing *ptr =3D 0 (where ptr points to a read-only page) or it executes an x86 instruction that is excessively long. I have found the code but I haven't figured out how it is being called yet. The core loop is just: for(;;) { sigaction(SIGSEGV, &action, NULL); sigaction(SIGILL, &action, NULL); sigaction(SIGBUS, &action, NULL); ret =3D sigsetjmp(jmp_env, 1); if (done()) break; if (ret) { /* verify signal */ } else { *ptr =3D 0; } } Code like that fundamentally can not be multi-threaded. So the only way the sigpending limit is being hit is if there are more processes running that code simultaneously than the size of the limit. Further it looks like stress-ng pushes RLIMIT_SIGPENDING as high as it will go before the test starts. > Also, the old code was very careful to only do the "get_user()" for > the *first* signal it added to the queue, and do the "put_user()" for > when removing the last signal. Exactly because those atomics are very > expensive. > > The new code just does a lot of these atomics unconditionally. Yes. That seems a likely culprit. > I dunno. The profile data in there is a bit hard to read, but there's > a lot more cachee misses, and a *lot* of node crossers: > >> 5961544 +190.4% 17314361 perf-stat.i.cache-misses >> 22107466 +119.2% 48457656 perf-stat.i.cache-referenc= es >> 163292 =C4=85 3% +4582.0% 7645410 perf-stat.i.node-load= -misses >> 227388 =C4=85 2% +3708.8% 8660824 perf-stat.i.node-loads > > and (probably as a result) average instruction costs have gone up enormou= sly: > >> 3.47 +66.8% 5.79 perf-stat.overall.cpi >> 22849 -65.6% 7866 perf-stat.overall.cycles-b= etween-cache-misses > > and it does seem to be at least partly about "put_ucounts()": > >> 0.00 +4.5 4.46 perf-profile.calltrace.cyc= les-pp.put_ucounts.__sigqueue_free.get_signal.arch_do_signal_or_restart.exi= t_to_user_mode_prepare > > and a lot of "get_ucounts()". > > But it may also be that the new "get sigpending" is just *so* much > more expensive than it used to be. That too is possible. That node-load-misses number does look like something is bouncing back and forth between the nodes a lot more. So I suspect stress-ng is running multiple copies of the sigsegv test in different processes at once. That really suggests cache line ping pong from get_ucounts and incrementing sigpending. It surprises me that obtaining the cache lines exclusively is the dominant cost on this code path but obtaining two cache lines exclusively instead of one cache cache line exclusively is consistent with a causing the exception delivery to take nearly twice as long. For the optimization we only care about the leaf count so with a little care we can restore the optimization. So that is probably the thing to do here. The fewer changes to worry about the less likely to find surprises. That said for this specific case there is a lot of potential room for improvement. As this is a per thread signal the code update sigpending in commit_cred and never worry about needing to pin the struct user_struct or struct ucounts. As this is a synchronous signal we could skip the sigpending increment, skip the signal queue entirely, and deliver the signal to user-space immediately. The removal of all cache ping pongs might make it worth it. There is also Thomas Gleixner's recent optimization to cache one sigqueue entry per task to give more predictable behavior. That would remove the cost of the allocation. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4109489684752241280==" MIME-Version: 1.0 From: Eric W. Biederman To: lkp@lists.01.org Subject: Re: 08ed4efad6: stress-ng.sigsegv.ops_per_sec -41.9% regression Date: Thu, 08 Apr 2021 13:44:43 -0500 Message-ID: In-Reply-To: List-Id: --===============4109489684752241280== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Linus Torvalds writes: > On Thu, Apr 8, 2021 at 1:32 AM kernel test robot wrote: >> >> FYI, we noticed a -41.9% regression of stress-ng.sigsegv.ops_per_sec due= to commit >> 08ed4efad684 ("[PATCH v10 6/9] Reimplement RLIMIT_SIGPENDING on top of u= counts") > > Ouch. We were cautiously optimistic when no test problems showed up from the last posting that there was nothing to look at here. Unfortunately it looks like the bots just missed the last posting. = So it seems we are finally pretty much at correct code in need of performance tuning. > I *think* this test may be testing "send so many signals that it > triggers the signal queue overflow case". > > And I *think* that the performance degradation may be due to lots of > unnecessary allocations, because ity looks like that commit changes > __sigqueue_alloc() to do > > struct sigqueue *q =3D kmem_cache_alloc(sigqueue_cachep, flags); > > *before* checking the signal limit, and then if the signal limit was > exceeded, it will just be free'd instead. > > The old code would check the signal count against RLIMIT_SIGPENDING > *first*, and if there were m ore pending signals then it wouldn't do > anything at all (including not incrementing that expensive atomic > count). This is an interesting test in a lot of ways as it is testing the synchronous signal delivery path caused by an exception. The test is either executing *ptr =3D 0 (where ptr points to a read-only page) or it executes an x86 instruction that is excessively long. I have found the code but I haven't figured out how it is being called yet. The core loop is just: for(;;) { sigaction(SIGSEGV, &action, NULL); sigaction(SIGILL, &action, NULL); sigaction(SIGBUS, &action, NULL); ret =3D sigsetjmp(jmp_env, 1); if (done()) break; if (ret) { /* verify signal */ } else { *ptr =3D 0; } } Code like that fundamentally can not be multi-threaded. So the only way the sigpending limit is being hit is if there are more processes running that code simultaneously than the size of the limit. Further it looks like stress-ng pushes RLIMIT_SIGPENDING as high as it will go before the test starts. > Also, the old code was very careful to only do the "get_user()" for > the *first* signal it added to the queue, and do the "put_user()" for > when removing the last signal. Exactly because those atomics are very > expensive. > > The new code just does a lot of these atomics unconditionally. Yes. That seems a likely culprit. > I dunno. The profile data in there is a bit hard to read, but there's > a lot more cachee misses, and a *lot* of node crossers: > >> 5961544 +190.4% 17314361 perf-stat.i.cache-misses >> 22107466 +119.2% 48457656 perf-stat.i.cache-referenc= es >> 163292 =C4=85 3% +4582.0% 7645410 perf-stat.i.node-load= -misses >> 227388 =C4=85 2% +3708.8% 8660824 perf-stat.i.node-loads > > and (probably as a result) average instruction costs have gone up enormou= sly: > >> 3.47 +66.8% 5.79 perf-stat.overall.cpi >> 22849 -65.6% 7866 perf-stat.overall.cycles-b= etween-cache-misses > > and it does seem to be at least partly about "put_ucounts()": > >> 0.00 +4.5 4.46 perf-profile.calltrace.cyc= les-pp.put_ucounts.__sigqueue_free.get_signal.arch_do_signal_or_restart.exi= t_to_user_mode_prepare > > and a lot of "get_ucounts()". > > But it may also be that the new "get sigpending" is just *so* much > more expensive than it used to be. That too is possible. That node-load-misses number does look like something is bouncing back and forth between the nodes a lot more. So I suspect stress-ng is running multiple copies of the sigsegv test in different processes at once. That really suggests cache line ping pong from get_ucounts and incrementing sigpending. It surprises me that obtaining the cache lines exclusively is the dominant cost on this code path but obtaining two cache lines exclusively instead of one cache cache line exclusively is consistent with a causing the exception delivery to take nearly twice as long. For the optimization we only care about the leaf count so with a little care we can restore the optimization. So that is probably the thing to do here. The fewer changes to worry about the less likely to find surprises. That said for this specific case there is a lot of potential room for improvement. As this is a per thread signal the code update sigpending in commit_cred and never worry about needing to pin the struct user_struct or struct ucounts. As this is a synchronous signal we could skip the sigpending increment, skip the signal queue entirely, and deliver the signal to user-space immediately. The removal of all cache ping pongs might make it worth it. There is also Thomas Gleixner's recent optimization to cache one sigqueue entry per task to give more predictable behavior. That would remove the cost of the allocation. Eric --===============4109489684752241280==--