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=-8.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 7A46BC433E2 for ; Mon, 14 Sep 2020 20:45:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0CD51206DB for ; Mon, 14 Sep 2020 20:45:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="JAPA/qzJ"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="JVGAZSnC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0CD51206DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3989C90000B; Mon, 14 Sep 2020 16:45:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27E84900008; Mon, 14 Sep 2020 16:45:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F83490000B; Mon, 14 Sep 2020 16:45:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id ED9CC900008 for ; Mon, 14 Sep 2020 16:45:19 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A8B7D3623 for ; Mon, 14 Sep 2020 20:45:09 +0000 (UTC) X-FDA: 77262846738.21.sheep03_300ad112710b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 798C9180442C3 for ; Mon, 14 Sep 2020 20:45:09 +0000 (UTC) X-HE-Tag: sheep03_300ad112710b X-Filterd-Recvd-Size: 10811 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Mon, 14 Sep 2020 20:45:08 +0000 (UTC) Message-Id: <20200914204209.256266093@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JAPA/qzJzqHcag6qcakOZ9GWUXDKy6NtfE7r1NQIWc0gTSVI1iY9yrfWEOEFzix8pmbAuS MuaADNs3pSiCLAI4n+a3p1Yf/IWnvCFznqLXHdFbrDe3FVowlmnsdQrS2jaIRBADVVI35z w4z5EtbZ4BM+lDYkm4gbkp+SUGbQKvIrUNGyKtK0Iy+a2fNL9PfeIjhLDWq/Rh541SefY6 UEZRJAC+1zAPbDuYa0LqAwZ3otlmljq7saTqU/AENBQStLBF6lG25DUU28wlzUFRs8NAHx Sc5WJ3V+SMr9bgVMgPIVxmsQXr7EAdha5VH1MxCb2AQt5zljIPUjkUY/FDZVaw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JVGAZSnCuZ9YvnhwM1nsyY3Yl860vCMg1V49xOerJHh7jF1cfp3RkRkcmNc+b0cld1O3y+ vBmqvqKHtYT11hAw== Date: Mon, 14 Sep 2020 22:42:09 +0200 From: Thomas Gleixner To: LKML Cc: linux-arch@vger.kernel.org, Linus Torvalds , Sebastian Andrzej Siewior , Valentin Schneider , Richard Henderson , Ivan Kokshaysky , Matt Turner , linux-alpha@vger.kernel.org, Jeff Dike , Richard Weinberger , Anton Ivanov , linux-um@lists.infradead.org, Brian Cain , linux-hexagon@vger.kernel.org, Geert Uytterhoeven , linux-m68k@lists.linux-m68k.org, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Will Deacon , Andrew Morton , linux-mm@kvack.org, Ingo Molnar , Russell King , linux-arm-kernel@lists.infradead.org, Chris Zankel , Max Filippov , linux-xtensa@linux-xtensa.org, Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, "Paul E. McKenney" , Josh Triplett , Mathieu Desnoyers , Lai Jiangshan , Shuah Khan , rcu@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [patch 00/13] preempt: Make preempt count unconditional MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 798C9180442C3 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: Rm9sa3MhCgpXaGlsZSB3b3JraW5nIG9uIHZhcmlvdXMgcHJlZW1wdCBjb3VudCByZWxhdGVkIHRo aW5ncywgSSBzdHVtYmxlZCAoYWdhaW4pCm92ZXIgdGhlIGluY29uc2lzdGVuY3kgb2Ygb3VyIHBy ZWVtcHQgY291bnQgaGFuZGxpbmcuCgpUaGUgaGFuZGxpbmcgb2YgcHJlZW1wdF9jb3VudCgpIGlz IGluY29uc2lzdGVudCBhY2Nyb3NzIGtlcm5lbApjb25maWd1cmF0aW9ucy4gT24ga2VybmVscyB3 aGljaCBoYXZlIFBSRUVNUFRfQ09VTlQ9bgpwcmVlbXB0X2Rpc2FibGUvZW5hYmxlKCkgYW5kIHRo ZSBsb2NrL3VubG9jayBmdW5jdGlvbnMgYXJlIG5vdCBhZmZlY3RpbmcKdGhlIHByZWVtcHQgY291 bnQsIG9ubHkgbG9jYWxfYmhfZGlzYWJsZS9lbmFibGUoKSBhbmQgX2JoIHZhcmlhbnRzIG9mCmxv Y2tpbmcsIHNvZnQgaW50ZXJydXB0IGRlbGl2ZXJ5LCBoYXJkIGludGVycnVwdCBhbmQgTk1JIGNv bnRleHQgYWZmZWN0IGl0LgoKSXQncyB0aGVyZWZvcmUgaW1wb3NzaWJsZSB0byBoYXZlIGEgY29u c2lzdGVudCBzZXQgb2YgY2hlY2tzIHdoaWNoIHByb3ZpZGUKaW5mb3JtYXRpb24gYWJvdXQgdGhl IGNvbnRleHQgaW4gd2hpY2ggYSBmdW5jdGlvbiBpcyBjYWxsZWQuIEluIG1hbnkgY2FzZXMKaXQg bWFrZXMgc2Vuc2UgdG8gaGF2ZSBzZXBlcmF0ZSBmdW5jdGlvbnMgZm9yIHNlcGVyYXRlIGNvbnRl eHRzLCBidXQgdGhlcmUKYXJlIHZhbGlkIHJlYXNvbnMgdG8gYXZvaWQgdGhhdCBhbmQgaGFuZGxl IGRpZmZlcmVudCBjYWxsaW5nIGNvbnRleHRzCmNvbmRpdGlvbmFsbHkuCgpUaGUgbGFjayBvZiBz dWNoIGluZGljYXRvcnMgd2hpY2ggd29yayBvbiBhbGwga2VybmVsIGNvbmZpZ3VyYXRpb3MgaXMg YQpjb25zdGFudCBzb3VyY2Ugb2YgdHJvdWJsZSBiZWNhdXNlIGRldmVsb3BlcnMgZWl0aGVyIGRv IG5vdCB1bmRlcnN0YW5kIHRoZQppbXBsaWNhdGlvbnMgb3IgdHJ5IHRvIHdvcmsgYXJvdW5kIHRo aXMgaW5jb25zaXN0ZW5jeSBpbiB3ZWlyZAp3YXlzLiBOZWl0aGVyIHNlZW0gdGhlc2UgaXNzdWVz IGJlIGNhdGNoZWQgYnkgcmV2aWV3ZXJzIGFuZCB0ZXN0aW5nLgoKUmVjZW50bHkgbWVyZ2VkIGNv ZGUgZG9lczoKCgkgZ2ZwID0gcHJlZW1wdGlibGUoKSA/IEdGUF9LRVJORUwgOiBHRlBfQVRPTUlD OwoKTG9va3Mgb2J2aW91c2x5IGNvcnJlY3QsIGV4Y2VwdCBmb3IgdGhlIGZhY3QgdGhhdCBwcmVl bXB0aWJsZSgpIGlzCnVuY29uZGl0aW9uYWxseSBmYWxzZSBmb3IgQ09ORklGX1BSRUVNUFRfQ09V TlQ9biwgaS5lLiBhbGwgYWxsb2NhdGlvbnMgaW4KdGhhdCBjb2RlIHVzZSBHRlBfQVRPTUlDIG9u IHN1Y2gga2VybmVscy4KCkF0dGVtcHRzIHRvIG1ha2UgcHJlZW1wdCBjb3VudCB1bmNvbmRpdGlv bmFsIGFuZCBjb25zaXN0ZW50IGhhdmUgYmVlbgpyZWplY3RlZCBpbiB0aGUgcGFzdCB3aXRoIGhh bmR3YXZpbmcgcGVyZm9ybWFuY2UgYXJndW1lbnRzLgoKRnJlc2hseSBjb25kdWN0ZWQgYmVuY2ht YXJrcyBkaWQgbm90IHJldmVhbCBhbnkgbWVhc3VyYWJsZSBpbXBhY3QgZnJvbQplbmFibGluZyBw cmVlbXB0IGNvdW50IHVuY29uZGl0aW9uYWxseS4gT24ga2VybmVscyB3aXRoIENPTkZJR19QUkVF TVBUX05PTkUKb3IgQ09ORklHX1BSRUVNUFRfVk9MVU5UQVJZIHRoZSBwcmVlbXB0IGNvdW50IGlz IG9ubHkgaW5jcmVtZW50ZWQgYW5kCmRlY3JlbWVudGVkIGJ1dCB0aGUgcmVzdWx0IG9mIHRoZSBk ZWNyZW1lbnQgaXMgbm90IHRlc3RlZC4gQ29udHJhcnkgdG8gdGhhdAplbmFibGluZyBDT05GSUdf UFJFRU1QVCB3aGljaCB0ZXN0cyB0aGUgcmVzdWx0IGhhcyBhIHNtYWxsIGJ1dCBtZWFzdXJhYmxl CmltcGFjdCBkdWUgdG8gdGhlIGNvbmRpdGlvbmFsIGJyYW5jaC9jYWxsLgoKSXQncyBhYm91dCB0 aW1lIHRvIG1ha2UgZXNzZW50aWFsIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIGtlcm5lbCBjb25zaXN0 ZW50CmFjY3Jvc3MgdGhlIHZhcmlvdXMgcHJlZW1wdGlvbiBtb2RlbHMuCgpUaGUgc2VyaWVzIGlz IGFsc28gYXZhaWxhYmxlIGZyb20gZ2l0OgoKICAgZ2l0Oi8vZ2l0Lmtlcm5lbC5vcmcvcHViL3Nj bS9saW51eC9rZXJuZWwvZ2l0L3RnbHgvZGV2ZWwuZ2l0IHByZWVtcHQKClRoYXQncyB0aGUgZmly c3QgcGFydCBvZiBhIGxhcmdlciBlZmZvcnQgcmVsYXRlZCB0byBwcmVlbXB0IGNvdW50OgoKIDEp IFRoZSBhbmFseXNpcyBvZiB0aGUgdXNhZ2Ugc2l0ZXMgb2YgaW5faW50ZXJydXB0KCksIGluX2F0 b21pYygpLAogICAgaW5fc29mdGlycSgpIGlzIHN0aWxsIG9uZ29pbmcsIGJ1dCBzbyBmYXIgdGhl IG51bWJlciBvZiBidWdneSB1c2VycyBpcwogICAgY2xlYXJseSB0aGUgdmFzdCBtYWpvcml0eS4g VGhlcmUgd2lsbCBiZSBzZXBlcmF0ZSBwYXRjaCBzZXJpZXMKICAgIChjdXJyZW50bHkgNDYgYW5k IGNvdW50aW5nKSB0byBhZGRyZXNzIHRoZXNlIGlzc3VlcyBvbmNlIHRoZSBhbmFseXNpcwogICAg aXMgY29tcGxldGUgaW4gdGhlIG5leHQgZGF5cy4KCiAyKSBUaGUgbG9uZyBkaXNjdXNzZWQgc3Rh dGUgdHJhY2tpbmcgb2YgbG9jYWwgaXJxIGRpc2FibGUgaW4gcHJlZW1wdCBjb3VudAogICAgd2hp Y2ggYWNjb3VudHMgaW50ZXJydXB0IGRpc2FibGVkIHNlY3Rpb25zIGFzIGF0b21pYyBhbmQgYXZv aWRzIGlzc3VpbmcKICAgIGNvc3RseSBpbnN0cnVjdGlvbnMgKHN0aSwgY2xpLCBwb3BmIG9yIHRo ZWlyIG5vbiBYODYgY291bnRlcnBhcnRzKSB3aGVuCiAgICB0aGUgc3RhdGUgZG9lcyBub3QgY2hh bmdlLCBpLmUuIG5lc3RlZCBpcnFfc2F2ZSgpIG9yIGlycV9yZXN0b3JlKCkuIEkKICAgIGhhdmUg dGhpcyB3b3JraW5nIG9uIFg4NiBhbHJlYWR5IGFuZCBjb250cmFyeSB0byBteSBlYXJsaWVyIGF0 dGVtcHRzCiAgICB0aGlzIHdhcyByZWFzb25hYmx5IHN0cmFpZ2h0IGZvcndhcmQgZHVlIHRvIHRo ZSByZWNlbnQgZW50cnkvZXhpdCBjb2RlCiAgICBjb25zb2xpZGF0aW9uLgoKICAgIFdoYXQgSSd2 ZSBub3QgZG9uZSB5ZXQgaXMgdG8gb3B0aW1pemUgdGhlIHByZWVtcHQgY291bnQgaGFuZGxpbmcK ICAgIG9mIHRoZSBbdW5dbG9ja19pcnEqIG9wZXJhdGlvbnMgc28gdGhleSBoYW5kbGUgdGhlIGlu dGVycnVwdCBkaXNhYmxlZAogICAgc3RhdGUgYW5kIHRoZSBwcmVlbXB0IGNvdW50IG1vZGlmaWNh dGlvbiBpbiBvbmUgZ28uIFRoYXQncyBhbiBvYnZpb3VzCiAgICBhZGQgb24sIGJ1dCBjb3JyZWN0 bmVzcyBmaXJzdCAuLi4KCiAzKSBMYXp5IGludGVycnVwdCBkaXNhYmxpbmcgYXMgYSBzdHJhaWdo dCBmb3J3YXJkIGV4dGVuc2lvbiB0byAjMi4gVGhpcwogICAgYXZvaWRzIHRoZSBhY3R1YWwgZGlz YWJsaW5nIGF0IHRoZSBDUFUgbGV2ZWwgY29tcGxldGVseSBhbmQgY2F0Y2hlcyBhbgogICAgaW5j b21pbmcgaW50ZXJydXB0IGluIHRoZSBsb3cgbGV2ZWwgZW50cnkgY29kZSwgbW9kaWZpZXMgdGhl IGludGVycnVwdAogICAgZGlzYWJsZWQgc3RhdGUgb24gdGhlIHJldHVybiBzdGFjaywgbm90ZXMg dGhlIGludGVycnVwdCBhcyBwZW5kaW5nIGluCiAgICBzb2Z0d2FyZSBhbmQgcmFpc2VzIGl0IGFn YWluIHdoZW4gaW50ZXJydXB0cyBhcmUgcmVlbmFibGVkLiBUaGlzIGhhcwogICAgc3RpbGwgYSBm ZXcgaXNzdWVzIHdoaWNoIEknbSBodW50aW5nIGRvd24gKGNwdWlkbGUgaXMgdW5oYXBweSAuLi4p CgpUaGFua3MsCgoJdGdseAotLS0KIGFyY2gvYXJtL2luY2x1ZGUvYXNtL2Fzc2VtYmxlci5oICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDExIC0tCiBhcmNoL2FybS9rZXJuZWwv aXdtbXh0LlMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgMiAK IGFyY2gvYXJtL21hY2gtZXA5M3h4L2NydW5jaC1iaXRzLlMgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAyIAogYXJjaC94dGVuc2Eva2VybmVsL2VudHJ5LlMgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDIgCiBkcml2ZXJzL2dwdS9kcm0vaTkxNS9L Y29uZmlnLmRlYnVnICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgMSAKIGRyaXZl cnMvZ3B1L2RybS9pOTE1L2k5MTVfdXRpbHMuaCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAzIAogaW5jbHVkZS9saW51eC9iaXRfc3BpbmxvY2suaCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgIDQgLQogaW5jbHVkZS9saW51eC9sb2NrZGVwLmggICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDYgLQogaW5jbHVkZS9s aW51eC9wYWdlbWFwLmggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgIDQgLQogaW5jbHVkZS9saW51eC9wcmVlbXB0LmggICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgMzcgKy0tLS0tLS0tLQogaW5jbHVkZS9saW51eC91YWNjZXNz LmggICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDYgLQoga2Vy bmVsL0tjb25maWcucHJlZW1wdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgIDQgLQoga2VybmVsL3NjaGVkL2NvcmUuYyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDYgLQogbGliL0tjb25maWcuZGVidWcgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDMgCiBsaWIvS2Nv bmZpZy5kZWJ1Zy5yZWogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAxNCArLS0KIHRvb2xzL3Rlc3Rpbmcvc2VsZnRlc3RzL3JjdXRvcnR1cmUvY29uZmlncy9y Y3UvU1JDVS10ICAgICAgICAgICAgfCAgICAxIAogdG9vbHMvdGVzdGluZy9zZWxmdGVzdHMvcmN1 dG9ydHVyZS9jb25maWdzL3JjdS9TUkNVLXUgICAgICAgICAgICB8ICAgIDEgCiB0b29scy90ZXN0 aW5nL3NlbGZ0ZXN0cy9yY3V0b3J0dXJlL2NvbmZpZ3MvcmN1L1RJTlkwMSAgICAgICAgICAgIHwg ICAgMSAKIHRvb2xzL3Rlc3Rpbmcvc2VsZnRlc3RzL3JjdXRvcnR1cmUvZG9jL1RJTllfUkNVLnR4 dCAgICAgICAgICAgICAgfCAgICA1IC0KIHRvb2xzL3Rlc3Rpbmcvc2VsZnRlc3RzL3JjdXRvcnR1 cmUvZG9jL1RSRUVfUkNVLWtjb25maWcudHh0ICAgICAgfCAgICAxIAogdG9vbHMvdGVzdGluZy9z ZWxmdGVzdHMvcmN1dG9ydHVyZS9mb3JtYWwvc3JjdS1jYm1jL3NyYy9jb25maWcuaCB8ICAgIDEg CiAyMSBmaWxlcyBjaGFuZ2VkLCAyMyBpbnNlcnRpb25zKCspLCA5MiBkZWxldGlvbnMoLSkKCgo= 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=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 EEE85C43461 for ; Mon, 14 Sep 2020 20:47:37 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 8EEAD20E65 for ; Mon, 14 Sep 2020 20:47:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nYCvp6IF"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="JAPA/qzJ"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="JVGAZSnC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8EEAD20E65 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Subject:To:From:Date:Message-Id: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=Sm6/kSGAjdRA6usFlzB5rcVI0BK1qVSfybEcHTG6WKM=; b=nYCvp6IFhd5w2BDSw9cf5IsUQa NEivmHwGlww19YkRY8l52kqF5mQEI+yCS4GMZ0NmP9o2XCWc/IqM5oL/vBchSF4ccoygokhM/G1Ka akfdq/nuNYfS3jkcuwmuVmUGHMHAsm7DJu2GXKtR7TzagO1LHFDaRFDZq9GFQaetkYocBK6uxjoQ9 GI/u1XQSrKYX0ouXS50zj9GkLjgggsAVIeZuxWCXnDnGgESCDgPDpVsZZPkdTiodUiA3vguLXOoQ1 rl7GJwvuc0YKxEbAcX0AT2AG7A66cXzZ88wyWfAVOEpNo+++qt/d5Jd1CkYL2wIyVFZDEzMFKv39m HonUqctA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kHvLc-000295-8s; Mon, 14 Sep 2020 20:45:12 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kHvLX-00025V-0d; Mon, 14 Sep 2020 20:45:08 +0000 Message-Id: <20200914204209.256266093@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JAPA/qzJzqHcag6qcakOZ9GWUXDKy6NtfE7r1NQIWc0gTSVI1iY9yrfWEOEFzix8pmbAuS MuaADNs3pSiCLAI4n+a3p1Yf/IWnvCFznqLXHdFbrDe3FVowlmnsdQrS2jaIRBADVVI35z w4z5EtbZ4BM+lDYkm4gbkp+SUGbQKvIrUNGyKtK0Iy+a2fNL9PfeIjhLDWq/Rh541SefY6 UEZRJAC+1zAPbDuYa0LqAwZ3otlmljq7saTqU/AENBQStLBF6lG25DUU28wlzUFRs8NAHx Sc5WJ3V+SMr9bgVMgPIVxmsQXr7EAdha5VH1MxCb2AQt5zljIPUjkUY/FDZVaw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JVGAZSnCuZ9YvnhwM1nsyY3Yl860vCMg1V49xOerJHh7jF1cfp3RkRkcmNc+b0cld1O3y+ vBmqvqKHtYT11hAw== Date: Mon, 14 Sep 2020 22:42:09 +0200 From: Thomas Gleixner To: LKML Subject: [patch 00/13] preempt: Make preempt count unconditional MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200914_164507_432725_C7BA1C60 X-CRM114-Status: GOOD ( 14.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , Peter Zijlstra , Sebastian Andrzej Siewior , Joonas Lahtinen , Lai Jiangshan , dri-devel@lists.freedesktop.org, Ben Segall , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-hexagon@vger.kernel.org, Will Deacon , Ingo Molnar , Anton Ivanov , linux-arch@vger.kernel.org, Vincent Guittot , Brian Cain , Richard Weinberger , Russell King , David Airlie , Ingo Molnar , Geert Uytterhoeven , Mel Gorman , intel-gfx@lists.freedesktop.org, Matt Turner , Valentin Schneider , linux-xtensa@linux-xtensa.org, Shuah Khan , "Paul E. McKenney" , Jeff Dike , linux-um@lists.infradead.org, Josh Triplett , Steven Rostedt , rcu@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Ivan Kokshaysky , Jani Nikula , Rodrigo Vivi , Dietmar Eggemann , linux-arm-kernel@lists.infradead.org, Richard Henderson , Chris Zankel , Max Filippov , Linus Torvalds , Daniel Vetter , linux-alpha@vger.kernel.org, Mathieu Desnoyers , Andrew Morton , Daniel Bristot de Oliveira Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Folks! While working on various preempt count related things, I stumbled (again) over the inconsistency of our preempt count handling. The handling of preempt_count() is inconsistent accross kernel configurations. On kernels which have PREEMPT_COUNT=n preempt_disable/enable() and the lock/unlock functions are not affecting the preempt count, only local_bh_disable/enable() and _bh variants of locking, soft interrupt delivery, hard interrupt and NMI context affect it. It's therefore impossible to have a consistent set of checks which provide information about the context in which a function is called. In many cases it makes sense to have seperate functions for seperate contexts, but there are valid reasons to avoid that and handle different calling contexts conditionally. The lack of such indicators which work on all kernel configuratios is a constant source of trouble because developers either do not understand the implications or try to work around this inconsistency in weird ways. Neither seem these issues be catched by reviewers and testing. Recently merged code does: gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; Looks obviously correct, except for the fact that preemptible() is unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in that code use GFP_ATOMIC on such kernels. Attempts to make preempt count unconditional and consistent have been rejected in the past with handwaving performance arguments. Freshly conducted benchmarks did not reveal any measurable impact from enabling preempt count unconditionally. On kernels with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY the preempt count is only incremented and decremented but the result of the decrement is not tested. Contrary to that enabling CONFIG_PREEMPT which tests the result has a small but measurable impact due to the conditional branch/call. It's about time to make essential functionality of the kernel consistent accross the various preemption models. The series is also available from git: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git preempt That's the first part of a larger effort related to preempt count: 1) The analysis of the usage sites of in_interrupt(), in_atomic(), in_softirq() is still ongoing, but so far the number of buggy users is clearly the vast majority. There will be seperate patch series (currently 46 and counting) to address these issues once the analysis is complete in the next days. 2) The long discussed state tracking of local irq disable in preempt count which accounts interrupt disabled sections as atomic and avoids issuing costly instructions (sti, cli, popf or their non X86 counterparts) when the state does not change, i.e. nested irq_save() or irq_restore(). I have this working on X86 already and contrary to my earlier attempts this was reasonably straight forward due to the recent entry/exit code consolidation. What I've not done yet is to optimize the preempt count handling of the [un]lock_irq* operations so they handle the interrupt disabled state and the preempt count modification in one go. That's an obvious add on, but correctness first ... 3) Lazy interrupt disabling as a straight forward extension to #2. This avoids the actual disabling at the CPU level completely and catches an incoming interrupt in the low level entry code, modifies the interrupt disabled state on the return stack, notes the interrupt as pending in software and raises it again when interrupts are reenabled. This has still a few issues which I'm hunting down (cpuidle is unhappy ...) Thanks, tglx --- arch/arm/include/asm/assembler.h | 11 -- arch/arm/kernel/iwmmxt.S | 2 arch/arm/mach-ep93xx/crunch-bits.S | 2 arch/xtensa/kernel/entry.S | 2 drivers/gpu/drm/i915/Kconfig.debug | 1 drivers/gpu/drm/i915/i915_utils.h | 3 include/linux/bit_spinlock.h | 4 - include/linux/lockdep.h | 6 - include/linux/pagemap.h | 4 - include/linux/preempt.h | 37 +--------- include/linux/uaccess.h | 6 - kernel/Kconfig.preempt | 4 - kernel/sched/core.c | 6 - lib/Kconfig.debug | 3 lib/Kconfig.debug.rej | 14 +-- tools/testing/selftests/rcutorture/configs/rcu/SRCU-t | 1 tools/testing/selftests/rcutorture/configs/rcu/SRCU-u | 1 tools/testing/selftests/rcutorture/configs/rcu/TINY01 | 1 tools/testing/selftests/rcutorture/doc/TINY_RCU.txt | 5 - tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt | 1 tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/config.h | 1 21 files changed, 23 insertions(+), 92 deletions(-) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 B731BC2D0E0 for ; Tue, 15 Sep 2020 07:07:50 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 71903206C9 for ; Tue, 15 Sep 2020 07:07:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="JAPA/qzJ"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="JVGAZSnC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 71903206C9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C89A26E84E; Tue, 15 Sep 2020 07:07:21 +0000 (UTC) Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0DBAA6E59F for ; Mon, 14 Sep 2020 20:45:09 +0000 (UTC) Message-Id: <20200914204209.256266093@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JAPA/qzJzqHcag6qcakOZ9GWUXDKy6NtfE7r1NQIWc0gTSVI1iY9yrfWEOEFzix8pmbAuS MuaADNs3pSiCLAI4n+a3p1Yf/IWnvCFznqLXHdFbrDe3FVowlmnsdQrS2jaIRBADVVI35z w4z5EtbZ4BM+lDYkm4gbkp+SUGbQKvIrUNGyKtK0Iy+a2fNL9PfeIjhLDWq/Rh541SefY6 UEZRJAC+1zAPbDuYa0LqAwZ3otlmljq7saTqU/AENBQStLBF6lG25DUU28wlzUFRs8NAHx Sc5WJ3V+SMr9bgVMgPIVxmsQXr7EAdha5VH1MxCb2AQt5zljIPUjkUY/FDZVaw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JVGAZSnCuZ9YvnhwM1nsyY3Yl860vCMg1V49xOerJHh7jF1cfp3RkRkcmNc+b0cld1O3y+ vBmqvqKHtYT11hAw== Date: Mon, 14 Sep 2020 22:42:09 +0200 From: Thomas Gleixner To: LKML Subject: [patch 00/13] preempt: Make preempt count unconditional MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 15 Sep 2020 07:07:18 +0000 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , Peter Zijlstra , Sebastian Andrzej Siewior , Lai Jiangshan , dri-devel@lists.freedesktop.org, Ben Segall , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-hexagon@vger.kernel.org, Will Deacon , Ingo Molnar , Anton Ivanov , linux-arch@vger.kernel.org, Vincent Guittot , Brian Cain , Richard Weinberger , Russell King , David Airlie , Ingo Molnar , Geert Uytterhoeven , Mel Gorman , intel-gfx@lists.freedesktop.org, Matt Turner , Valentin Schneider , linux-xtensa@linux-xtensa.org, Shuah Khan , "Paul E. McKenney" , Jeff Dike , linux-um@lists.infradead.org, Josh Triplett , Steven Rostedt , rcu@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Ivan Kokshaysky , Rodrigo Vivi , Dietmar Eggemann , linux-arm-kernel@lists.infradead.org, Richard Henderson , Chris Zankel , Max Filippov , Linus Torvalds , linux-alpha@vger.kernel.org, Mathieu Desnoyers , Andrew Morton , Daniel Bristot de Oliveira Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Folks! While working on various preempt count related things, I stumbled (again) over the inconsistency of our preempt count handling. The handling of preempt_count() is inconsistent accross kernel configurations. On kernels which have PREEMPT_COUNT=n preempt_disable/enable() and the lock/unlock functions are not affecting the preempt count, only local_bh_disable/enable() and _bh variants of locking, soft interrupt delivery, hard interrupt and NMI context affect it. It's therefore impossible to have a consistent set of checks which provide information about the context in which a function is called. In many cases it makes sense to have seperate functions for seperate contexts, but there are valid reasons to avoid that and handle different calling contexts conditionally. The lack of such indicators which work on all kernel configuratios is a constant source of trouble because developers either do not understand the implications or try to work around this inconsistency in weird ways. Neither seem these issues be catched by reviewers and testing. Recently merged code does: gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; Looks obviously correct, except for the fact that preemptible() is unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in that code use GFP_ATOMIC on such kernels. Attempts to make preempt count unconditional and consistent have been rejected in the past with handwaving performance arguments. Freshly conducted benchmarks did not reveal any measurable impact from enabling preempt count unconditionally. On kernels with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY the preempt count is only incremented and decremented but the result of the decrement is not tested. Contrary to that enabling CONFIG_PREEMPT which tests the result has a small but measurable impact due to the conditional branch/call. It's about time to make essential functionality of the kernel consistent accross the various preemption models. The series is also available from git: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git preempt That's the first part of a larger effort related to preempt count: 1) The analysis of the usage sites of in_interrupt(), in_atomic(), in_softirq() is still ongoing, but so far the number of buggy users is clearly the vast majority. There will be seperate patch series (currently 46 and counting) to address these issues once the analysis is complete in the next days. 2) The long discussed state tracking of local irq disable in preempt count which accounts interrupt disabled sections as atomic and avoids issuing costly instructions (sti, cli, popf or their non X86 counterparts) when the state does not change, i.e. nested irq_save() or irq_restore(). I have this working on X86 already and contrary to my earlier attempts this was reasonably straight forward due to the recent entry/exit code consolidation. What I've not done yet is to optimize the preempt count handling of the [un]lock_irq* operations so they handle the interrupt disabled state and the preempt count modification in one go. That's an obvious add on, but correctness first ... 3) Lazy interrupt disabling as a straight forward extension to #2. This avoids the actual disabling at the CPU level completely and catches an incoming interrupt in the low level entry code, modifies the interrupt disabled state on the return stack, notes the interrupt as pending in software and raises it again when interrupts are reenabled. This has still a few issues which I'm hunting down (cpuidle is unhappy ...) Thanks, tglx --- arch/arm/include/asm/assembler.h | 11 -- arch/arm/kernel/iwmmxt.S | 2 arch/arm/mach-ep93xx/crunch-bits.S | 2 arch/xtensa/kernel/entry.S | 2 drivers/gpu/drm/i915/Kconfig.debug | 1 drivers/gpu/drm/i915/i915_utils.h | 3 include/linux/bit_spinlock.h | 4 - include/linux/lockdep.h | 6 - include/linux/pagemap.h | 4 - include/linux/preempt.h | 37 +--------- include/linux/uaccess.h | 6 - kernel/Kconfig.preempt | 4 - kernel/sched/core.c | 6 - lib/Kconfig.debug | 3 lib/Kconfig.debug.rej | 14 +-- tools/testing/selftests/rcutorture/configs/rcu/SRCU-t | 1 tools/testing/selftests/rcutorture/configs/rcu/SRCU-u | 1 tools/testing/selftests/rcutorture/configs/rcu/TINY01 | 1 tools/testing/selftests/rcutorture/doc/TINY_RCU.txt | 5 - tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt | 1 tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/config.h | 1 21 files changed, 23 insertions(+), 92 deletions(-) _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 BD29BC433E2 for ; Mon, 14 Sep 2020 20:55:05 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 78A992193E for ; Mon, 14 Sep 2020 20:55:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="JAPA/qzJ"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="JVGAZSnC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 78A992193E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9A6DC6E5A9; Mon, 14 Sep 2020 20:54:58 +0000 (UTC) Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by gabe.freedesktop.org (Postfix) with ESMTPS id EA64E6E5AB for ; Mon, 14 Sep 2020 20:54:55 +0000 (UTC) Message-Id: <20200914204209.256266093@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JAPA/qzJzqHcag6qcakOZ9GWUXDKy6NtfE7r1NQIWc0gTSVI1iY9yrfWEOEFzix8pmbAuS MuaADNs3pSiCLAI4n+a3p1Yf/IWnvCFznqLXHdFbrDe3FVowlmnsdQrS2jaIRBADVVI35z w4z5EtbZ4BM+lDYkm4gbkp+SUGbQKvIrUNGyKtK0Iy+a2fNL9PfeIjhLDWq/Rh541SefY6 UEZRJAC+1zAPbDuYa0LqAwZ3otlmljq7saTqU/AENBQStLBF6lG25DUU28wlzUFRs8NAHx Sc5WJ3V+SMr9bgVMgPIVxmsQXr7EAdha5VH1MxCb2AQt5zljIPUjkUY/FDZVaw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JVGAZSnCuZ9YvnhwM1nsyY3Yl860vCMg1V49xOerJHh7jF1cfp3RkRkcmNc+b0cld1O3y+ vBmqvqKHtYT11hAw== Date: Mon, 14 Sep 2020 22:42:09 +0200 From: Thomas Gleixner To: LKML MIME-Version: 1.0 Subject: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , Peter Zijlstra , Sebastian Andrzej Siewior , Lai Jiangshan , dri-devel@lists.freedesktop.org, Ben Segall , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-hexagon@vger.kernel.org, Will Deacon , Ingo Molnar , Anton Ivanov , linux-arch@vger.kernel.org, Brian Cain , Richard Weinberger , Russell King , David Airlie , Ingo Molnar , Geert Uytterhoeven , Mel Gorman , intel-gfx@lists.freedesktop.org, Matt Turner , Valentin Schneider , linux-xtensa@linux-xtensa.org, Shuah Khan , "Paul E. McKenney" , Jeff Dike , linux-um@lists.infradead.org, Josh Triplett , Steven Rostedt , rcu@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Ivan Kokshaysky , Dietmar Eggemann , linux-arm-kernel@lists.infradead.org, Richard Henderson , Chris Zankel , Max Filippov , Linus Torvalds , linux-alpha@vger.kernel.org, Mathieu Desnoyers , Andrew Morton , Daniel Bristot de Oliveira Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Folks! While working on various preempt count related things, I stumbled (again) over the inconsistency of our preempt count handling. The handling of preempt_count() is inconsistent accross kernel configurations. On kernels which have PREEMPT_COUNT=n preempt_disable/enable() and the lock/unlock functions are not affecting the preempt count, only local_bh_disable/enable() and _bh variants of locking, soft interrupt delivery, hard interrupt and NMI context affect it. It's therefore impossible to have a consistent set of checks which provide information about the context in which a function is called. In many cases it makes sense to have seperate functions for seperate contexts, but there are valid reasons to avoid that and handle different calling contexts conditionally. The lack of such indicators which work on all kernel configuratios is a constant source of trouble because developers either do not understand the implications or try to work around this inconsistency in weird ways. Neither seem these issues be catched by reviewers and testing. Recently merged code does: gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; Looks obviously correct, except for the fact that preemptible() is unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in that code use GFP_ATOMIC on such kernels. Attempts to make preempt count unconditional and consistent have been rejected in the past with handwaving performance arguments. Freshly conducted benchmarks did not reveal any measurable impact from enabling preempt count unconditionally. On kernels with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY the preempt count is only incremented and decremented but the result of the decrement is not tested. Contrary to that enabling CONFIG_PREEMPT which tests the result has a small but measurable impact due to the conditional branch/call. It's about time to make essential functionality of the kernel consistent accross the various preemption models. The series is also available from git: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git preempt That's the first part of a larger effort related to preempt count: 1) The analysis of the usage sites of in_interrupt(), in_atomic(), in_softirq() is still ongoing, but so far the number of buggy users is clearly the vast majority. There will be seperate patch series (currently 46 and counting) to address these issues once the analysis is complete in the next days. 2) The long discussed state tracking of local irq disable in preempt count which accounts interrupt disabled sections as atomic and avoids issuing costly instructions (sti, cli, popf or their non X86 counterparts) when the state does not change, i.e. nested irq_save() or irq_restore(). I have this working on X86 already and contrary to my earlier attempts this was reasonably straight forward due to the recent entry/exit code consolidation. What I've not done yet is to optimize the preempt count handling of the [un]lock_irq* operations so they handle the interrupt disabled state and the preempt count modification in one go. That's an obvious add on, but correctness first ... 3) Lazy interrupt disabling as a straight forward extension to #2. This avoids the actual disabling at the CPU level completely and catches an incoming interrupt in the low level entry code, modifies the interrupt disabled state on the return stack, notes the interrupt as pending in software and raises it again when interrupts are reenabled. This has still a few issues which I'm hunting down (cpuidle is unhappy ...) Thanks, tglx --- arch/arm/include/asm/assembler.h | 11 -- arch/arm/kernel/iwmmxt.S | 2 arch/arm/mach-ep93xx/crunch-bits.S | 2 arch/xtensa/kernel/entry.S | 2 drivers/gpu/drm/i915/Kconfig.debug | 1 drivers/gpu/drm/i915/i915_utils.h | 3 include/linux/bit_spinlock.h | 4 - include/linux/lockdep.h | 6 - include/linux/pagemap.h | 4 - include/linux/preempt.h | 37 +--------- include/linux/uaccess.h | 6 - kernel/Kconfig.preempt | 4 - kernel/sched/core.c | 6 - lib/Kconfig.debug | 3 lib/Kconfig.debug.rej | 14 +-- tools/testing/selftests/rcutorture/configs/rcu/SRCU-t | 1 tools/testing/selftests/rcutorture/configs/rcu/SRCU-u | 1 tools/testing/selftests/rcutorture/configs/rcu/TINY01 | 1 tools/testing/selftests/rcutorture/doc/TINY_RCU.txt | 5 - tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt | 1 tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/config.h | 1 21 files changed, 23 insertions(+), 92 deletions(-) _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: [patch 00/13] preempt: Make preempt count unconditional Date: Mon, 14 Sep 2020 22:42:09 +0200 Message-ID: <20200914204209.256266093@linutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Subject:To:From:Date:Message-Id: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=Sm6/kSGAjdRA6usFlzB5rcVI0BK1qVSfybEcHTG6WKM=; b=nYCvp6IFhd5w2BDSw9cf5IsUQa NEivmHwGlww19YkRY8l52kqF5mQEI+yCS4GMZ0NmP9o2XCWc/IqM5oL/vBchSF4ccoygokhM/G1Ka akfdq/nuNYfS3jkcuwmuVmUGHMHAsm7DJu2GXKtR7TzagO1LHFDaRFDZq9GFQaetkYocBK6uxjoQ9 GI/u1XQSrKYX0ouXS50zj9GkLjgggsAVIeZuxWCXnDnGgESCDgPDpVsZZPkdTiodUiA3vguLXOoQ1 rl7GJwvuc0YKxEbAcX0AT2AG7A66cXzZ88wyWfAVOEpNo+++qt/d5Jd1CkYL2wIyVFZDEzMFKv39m HonUqctA==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JAPA/qzJzqHcag6qcakOZ9GWUXDKy6NtfE7r1NQIWc0gTSVI1iY9yrfWEOEFzix8pmbAuS MuaADNs3pSiCLAI4n+a3p1Yf/IWnvCFznqLXHdFbrDe3FVowlmnsdQrS2jaIRBADVVI35z w4z5EtbZ4BM+lDYkm4gbkp+SUGbQKvIrUNGyKtK0Iy+a2fNL9PfeIjhLDWq/Rh541SefY6 UEZRJAC+1zAPbDuYa0LqAwZ3otlmljq7saTqU/AENBQStLBF6lG25DUU28wlzUFRs8NAHx Sc5WJ3V+SMr9bgVMgPIVxmsQXr7EAdha5VH1MxCb2AQt5zljIPUjkUY/FDZVaw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1600116304; h=from:from: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; bh=9WPslsayaKn9l4KRCy6vC0tA0OD05xl/cJA1zjQzh9Q=; b=JVGAZSnCuZ9YvnhwM1nsyY3Yl860vCMg1V49xOerJHh7jF1cfp3RkRkcmNc+b0cld1O3y+ vBmqvqKHtYT11hAw== List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane-mx.org@lists.infradead.org To: LKML Cc: Juri Lelli , Peter Zijlstra , Sebastian Andrzej Siewior , Joonas Lahtinen , Lai Jiangshan , dri-devel@lists.freedesktop.org, Ben Segall , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-hexagon@vger.kernel.org, Will Deacon , Ingo Molnar , Anton Ivanov , linux-arch@vger.kernel.org, Vincent Guittot , Brian Cain , Richard Weinberger , Russell King , David Airlie , Ingo Molnar , Geert Uytterhoeven , Mel Gorman , intel-gfx@lists.freedesktop.org, Matt Turner , Valentin Folks! While working on various preempt count related things, I stumbled (again) over the inconsistency of our preempt count handling. The handling of preempt_count() is inconsistent accross kernel configurations. On kernels which have PREEMPT_COUNT=n preempt_disable/enable() and the lock/unlock functions are not affecting the preempt count, only local_bh_disable/enable() and _bh variants of locking, soft interrupt delivery, hard interrupt and NMI context affect it. It's therefore impossible to have a consistent set of checks which provide information about the context in which a function is called. In many cases it makes sense to have seperate functions for seperate contexts, but there are valid reasons to avoid that and handle different calling contexts conditionally. The lack of such indicators which work on all kernel configuratios is a constant source of trouble because developers either do not understand the implications or try to work around this inconsistency in weird ways. Neither seem these issues be catched by reviewers and testing. Recently merged code does: gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC; Looks obviously correct, except for the fact that preemptible() is unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in that code use GFP_ATOMIC on such kernels. Attempts to make preempt count unconditional and consistent have been rejected in the past with handwaving performance arguments. Freshly conducted benchmarks did not reveal any measurable impact from enabling preempt count unconditionally. On kernels with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY the preempt count is only incremented and decremented but the result of the decrement is not tested. Contrary to that enabling CONFIG_PREEMPT which tests the result has a small but measurable impact due to the conditional branch/call. It's about time to make essential functionality of the kernel consistent accross the various preemption models. The series is also available from git: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git preempt That's the first part of a larger effort related to preempt count: 1) The analysis of the usage sites of in_interrupt(), in_atomic(), in_softirq() is still ongoing, but so far the number of buggy users is clearly the vast majority. There will be seperate patch series (currently 46 and counting) to address these issues once the analysis is complete in the next days. 2) The long discussed state tracking of local irq disable in preempt count which accounts interrupt disabled sections as atomic and avoids issuing costly instructions (sti, cli, popf or their non X86 counterparts) when the state does not change, i.e. nested irq_save() or irq_restore(). I have this working on X86 already and contrary to my earlier attempts this was reasonably straight forward due to the recent entry/exit code consolidation. What I've not done yet is to optimize the preempt count handling of the [un]lock_irq* operations so they handle the interrupt disabled state and the preempt count modification in one go. That's an obvious add on, but correctness first ... 3) Lazy interrupt disabling as a straight forward extension to #2. This avoids the actual disabling at the CPU level completely and catches an incoming interrupt in the low level entry code, modifies the interrupt disabled state on the return stack, notes the interrupt as pending in software and raises it again when interrupts are reenabled. This has still a few issues which I'm hunting down (cpuidle is unhappy ...) Thanks, tglx --- arch/arm/include/asm/assembler.h | 11 -- arch/arm/kernel/iwmmxt.S | 2 arch/arm/mach-ep93xx/crunch-bits.S | 2 arch/xtensa/kernel/entry.S | 2 drivers/gpu/drm/i915/Kconfig.debug | 1 drivers/gpu/drm/i915/i915_utils.h | 3 include/linux/bit_spinlock.h | 4 - include/linux/lockdep.h | 6 - include/linux/pagemap.h | 4 - include/linux/preempt.h | 37 +--------- include/linux/uaccess.h | 6 - kernel/Kconfig.preempt | 4 - kernel/sched/core.c | 6 - lib/Kconfig.debug | 3 lib/Kconfig.debug.rej | 14 +-- tools/testing/selftests/rcutorture/configs/rcu/SRCU-t | 1 tools/testing/selftests/rcutorture/configs/rcu/SRCU-u | 1 tools/testing/selftests/rcutorture/configs/rcu/TINY01 | 1 tools/testing/selftests/rcutorture/doc/TINY_RCU.txt | 5 - tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt | 1 tools/testing/selftests/rcutorture/formal/srcu-cbmc/src/config.h | 1 21 files changed, 23 insertions(+), 92 deletions(-)