Message ID | 20231107230822.371443-1-ankur.a.arora@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp572518vqo; Tue, 7 Nov 2023 15:10:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IHt8PMR+Aa5KV6lfletPgpnVRidu8cmP9x27iE0Jgyy1KvWQPjehj71LNyNGkNo0gVBL7MC X-Received: by 2002:a17:902:8f8c:b0:1cc:665d:f818 with SMTP id z12-20020a1709028f8c00b001cc665df818mr354782plo.68.1699398618066; Tue, 07 Nov 2023 15:10:18 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1699398618; cv=pass; d=google.com; s=arc-20160816; b=KY9+izx/fI7RB8USM1kGzfzb+cx5hfIJ3jMtL6x/fCY1pL8Cv5jcS/ZyvuhoBeFjfG Ix5w9ZQKGNgVQz8K9l/Dj10W9Pp751U9qMPnQ4S+s5jM/suU+yBwsTYXq7BqhAemxID7 7ZXX2GJu7bSxees/JHVcozdiL2mDO3W7uxVveGRXx4SmIuLAE2hDl+OkpOoVTYxNqPK6 0TNtIIgEmDTNDexUYvPu+KHjNLiddHx7zWsD+rvPmjYquFUCJA4klMEpE/oRIjv1cPYO urkWo4qAKkV3KzR7vml5qXiyNKxwog7aiYhpdVcRjRLYwLkML+aH5HA6vdEnd4OJKOE3 TdnA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=zK8SFzx6JjVEKci+tBZyL2d70uL/RG8LSxDqG81d3JA=; fh=I9yqJZf1IyHAQ5R68PAKHEuxc8w5JMY61Ied8wG0kb0=; b=iDMDwzRPJLlEbFUjdMuDn5GgaLE+iWAC/HAwPPLy5rFE4w6GA817EVHcH/s55pg2eJ vVboUG8GjMSWPv7T2Qm831badmvt4JN4DYj23mKmeArMj9SYO6zsBAEzARJDCNo3vgIw +D/qMBv0p2fGIJlsi1KaTb7M44EHAVxcXkjTzZDrcLatlF71bC+RklKp4fJ8RjGwF2m+ lt6fih6wrOAiWy+5opWCULJwYG8TKkp9NscqRh/pA/ZhupWU7kTaEGzKtPtyaGihRoCk uQcgPVhkI9+WSEomCwCuC2HugxaFxXc8i9j5w0zd7DFyVpLdfKZJZMT3kB2AHW1tSTZa 8vHQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=NKEQwCiA; dkim=pass header.i=@oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=x4HdgYbC; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id e9-20020a170902e0c900b001cc0e37524bsi727050pla.212.2023.11.07.15.10.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 15:10:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=NKEQwCiA; dkim=pass header.i=@oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=x4HdgYbC; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 10E7C81A2053; Tue, 7 Nov 2023 15:10:06 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344153AbjKGXJm (ORCPT <rfc822;lhua1029@gmail.com> + 32 others); Tue, 7 Nov 2023 18:09:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234175AbjKGXJj (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Nov 2023 18:09:39 -0500 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0910B10D1 for <linux-kernel@vger.kernel.org>; Tue, 7 Nov 2023 15:09:36 -0800 (PST) Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3A7LK6Lq026463; Tue, 7 Nov 2023 23:08:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : content-transfer-encoding : content-type : mime-version; s=corp-2023-03-30; bh=zK8SFzx6JjVEKci+tBZyL2d70uL/RG8LSxDqG81d3JA=; b=NKEQwCiAfgp3pJb2anY0CClEi4FMqkQ1xDK2Qyp2wUqDnTXcpfmzpY07MsQvRNmcZjPB 1biidY3UUYH5ovl4pLYuu4ajoYonZR6z93naAV4PuD2bNeT/85i7oyBlYB6cxSdHyxHb 5rDGmVpQ1u1+4eJg0NVKwgjM5iTbIxg5Y7GkUgm4CGIsqr8V4Y4rsXCUw3KMs6NARt99 l3tg1gzeyuu/+osKh7GNhNuSkoMn8BenBjTPue1fhcHKgFMkvZWz9YtAEcwI94kxPhWz zBAfPH42SYuhAxr4/o/mQQmAqIh0PtK0IzIsv7DBXVWpGmR8bCsUkF2pImcPUxAhAZlz kQ== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3u7w2106ut-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Nov 2023 23:08:29 +0000 Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 3A7N3tUW010979; Tue, 7 Nov 2023 23:08:28 GMT Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2100.outbound.protection.outlook.com [104.47.58.100]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3u7w1tv94e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Nov 2023 23:08:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O66h11kv6FJUxDYcbB5rlGAHepZGVteYkwskpd80All0VZ4dk6q6bkSISfi7DTbKPz1XqUtWCQXAjDt669WwusTtiqJhLVue0XQArWZ7mjXaXtima2Gc5mzKrGUcdyjaTtRlwjt1DEht+4k2EX7m+PfXvF5XHlUDUsYPrs417ZLPixPBND2+b7QHwOOxF5w5RuaW934xPR675EIR//c1PeDiXmBgaYnyKd1tZAOVTFzFzor+KKr8meuMYTfQxz19txEM9jGSkKdbfJDhW2gAsFMXor8vY2htY4CuYGjW6kk+mSyIHtCtCSveT2jRBRlSiOX81kuWJVtgyX0zOqI9CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zK8SFzx6JjVEKci+tBZyL2d70uL/RG8LSxDqG81d3JA=; b=LLpn22HrZjK0iPVvhQGdWab2KpjwxMDvDh6xF70d8LnlaArN4sqvdXy7+ZObYQ0YtipHWdnTkdnlaV/lmhuzmodwAYZbMNM38z6rfuvq7QearGS17l7/za094S4I7KzUIMroH3BY2OLErxCYnfaypoY/CHQLUn4/p/fCKXd7uuJGtqEQmTAo4xKOLgB3+N/u4PgGN5oJpI8szQCu9fVRPy+ZwWI/XJzFUF8ncqRNrj4Abnyrgfn4cBu8k28lxYAmgBKGyNjFVrxoufiDv8+KKGZ36aJRhMUiwYRHqQ9edBuN5zSOsumeIK6r6805skCdR09wYX/UuBen3kOudf7ITg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zK8SFzx6JjVEKci+tBZyL2d70uL/RG8LSxDqG81d3JA=; b=x4HdgYbCpPPhDE4ZRqEdm3eyzAf7E857m2UzlXYoZ/GTLJ1MhmBorSmoILpDPb/4qx4shI4KkYajRcwSjb3GIKsy9qcKq5nJnz0HahM6kCr+7Q3SS2iV62LyZTDX5eejCkQye7VIOX+DkDg4+Hn0sC6meazvYF+S2Lv8PGX3bj4= Received: from DM8PR10MB5416.namprd10.prod.outlook.com (2603:10b6:8:3f::19) by PH7PR10MB7010.namprd10.prod.outlook.com (2603:10b6:510:274::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.25; Tue, 7 Nov 2023 23:08:25 +0000 Received: from DM8PR10MB5416.namprd10.prod.outlook.com ([fe80::c72:c098:4fc2:629b]) by DM8PR10MB5416.namprd10.prod.outlook.com ([fe80::c72:c098:4fc2:629b%4]) with mapi id 15.20.6954.028; Tue, 7 Nov 2023 23:08:25 +0000 From: Ankur Arora <ankur.a.arora@oracle.com> To: linux-kernel@vger.kernel.org Cc: tglx@linutronix.de, peterz@infradead.org, torvalds@linux-foundation.org, paulmck@kernel.org, linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, mingo@kernel.org, bristot@kernel.org, mathieu.desnoyers@efficios.com, geert@linux-m68k.org, glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com, mattst88@gmail.com, krypton@ulrich-teichert.org, rostedt@goodmis.org, David.Laight@ACULAB.COM, richard@nod.at, mjguzik@gmail.com, Ankur Arora <ankur.a.arora@oracle.com>, Julia Lawall <Julia.Lawall@inria.fr>, Nicolas Palix <nicolas.palix@imag.fr> Subject: [RFC PATCH 57/86] coccinelle: script to remove cond_resched() Date: Tue, 7 Nov 2023 15:07:53 -0800 Message-Id: <20231107230822.371443-1-ankur.a.arora@oracle.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20231107215742.363031-1-ankur.a.arora@oracle.com> References: <20231107215742.363031-1-ankur.a.arora@oracle.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: MW4PR04CA0331.namprd04.prod.outlook.com (2603:10b6:303:8a::6) To DM8PR10MB5416.namprd10.prod.outlook.com (2603:10b6:8:3f::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM8PR10MB5416:EE_|PH7PR10MB7010:EE_ X-MS-Office365-Filtering-Correlation-Id: cfc9d6cb-b1ab-4b0f-996f-08dbdfe671c7 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: x5XANYS1fInMB+l7L72Xsq+KLEtLLwu6NcMM1VyhblfvZjMELnaqv7VLVvMj4OaaacN5UmSIUV4ly9wzVR5lIXCqXnEvY1ZHU38TOm2ZNwYoLRGuV/dBltjIFmlH41Ql4YUtGziVBuBBV8s3FvEtEOxjIBt+saOiWEzucDN8gEvOr5TtX54oDvkL0hBQshQcyOtqWfOVAVox3e47q8wbzGWP3nQkyVxAAaYKWO9euhCk2wwaTvhXNPugWgX68C/BPySi0jKI/hBxtZ87WRazx3BptaxBPj9uubiaKN1d3aHOWQn2KRvKroH5dAEQ06Rg5F5cCLY4GSyNwFoUCb2vXjStI6BvsnV0263pRzSvAnYA0yJIrc3vDNyN/NGEnUTgVXzP2b+18/eakHNOiFPQRHSlXJNT6G+DGmv+/eUQ3v6g9lOkcBb8HC5YInYuHZirSuhJ2vcweoagTUaIa9PpLujZTdnu2LZkpCwlCEMULos5j6wre0r+lBZc20RaigUSgrwkpYz1chNs9Gx1huiXe9ba7IB8y7C+HJzXle2Uzr20dMSjPf7Cr+UmSbKLOD4i X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM8PR10MB5416.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(396003)(376002)(136003)(346002)(39860400002)(230922051799003)(451199024)(64100799003)(186009)(1800799009)(2906002)(7416002)(7406005)(6486002)(478600001)(6666004)(54906003)(8676002)(316002)(66556008)(6916009)(66946007)(5660300002)(66476007)(4326008)(8936002)(6506007)(2616005)(41300700001)(1076003)(26005)(83380400001)(6512007)(38100700002)(103116003)(86362001)(36756003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: G6rJbBB/nG5+yQw8C75xwNEb0oTLrR2vHz5hM7R0lrROez2FUOnMjx7iGIGYJOJi2dZph8PMoMK6zahixJdcNkS8ug7+liGDS5DAMe0sP77o1U1a23Qi56ca1nqDS2u1FAZE3hKATM4vibHaemc6MjngDczXzxqmked/XC8jK3y9MCBYni0Dag/na/Gui8AhnNFQ2+6RS+oej5CzFb3g4kg1sMjg8JlONpWj2J6x45cJwAJIHquozJga/pENywYikP5tdaD9tWYN4/wm7cLIbyE8Ibr8fIbO7XVcKRBOCOC3BfqHkqpr3Fle/MqGKVU8Xk+RlKBP45c3aOJ9Ehb32TKi1GggSeYVdI23O2klkcq8xwgbD+xruc5mboEfH7ZDZQuyQXY4IHAfWTU8qPoNLUMAePAtqmlY5fbhOUqoLwRARWokuDDht/1qBISO/EKnunuK6DfOoH8IBXB+I/DgshY5G7b2pDtc98fnWn1HKmlxRZOQgGcIGj517uCoK40hJlbgDWpC9zmlj1NfBhdrUYm4qc7e+ed+u4ZVaMdOooZj9G8cDy46q13v442T7KL5ZbecogfZlCcv/Ti87c/tcuEcl6nWy3U4Vd3Vd//vfwuUwZ6PE69iMSFBKwy0+8KoeZZlxVStTNoKR2UbnXZyHh5VZ6Jco62d+/gjX9vXwgsJrNWZ8jkiYGQCWrHL/K4Qpc2hD65KLP+kgoDJ8+CljPaTh6Mmgw9VkbypwS5/DZg/0bCWQatlmDyUkgKLWMLz/HDdTSPrOclLT2tKm6Jh/e8bI2UDzMV0R3EuxJNJsDVHtxvjEzwsqfqHaxhovjnlu/WaLh9bofdQS1vU6VuLURIqQQePsx1bJ4oNqKDz+ckGop+DbjD3rpQRbncWmRtarC/A/baXJC/gu3GXTkReQe32imI1Bs2mTWUM7Y7o/MJfTp4tfWkkkrKKyhCs3Qkxf0QeMDqVu9bXTg4zv3r9veGiRzjFJQ8CU1lU53pdR5nuRTKvUbYBMd1zHZVoI+W49fPnrd6iJq24X8TMFp/o7HLeZ4PdPDkGYedtdNifbTLUNh8QZmvxxE8k7NWLW5zUk+OKBevBSo04laA1SOg7/8ZaJrkomSRZf+/jPCwONEgdl3MRKZ4m1OsZREo/BEVr4FhzVuoAnXgKi+Zd3/gVVBHOC0j2O9aWSHBleiDyJQd1lBRbonOMfR1sRMTLQ9pdKsnlGGZej5uMp0KStb5GDN+L1A1zReSw6jUBNPLfdBXxIAU8l53ghWvn/M76VQ6Xtbx0G8jjUzaiXPAG4cumg0xyO9dMcy9+wrOCnV7B90dOYeS7BSEGxXK0ERSKvnGF+/hxgX2BgYxLy1CrpkFUzjfUWHs8AZqSuoPD4ZeGNihfYPBst2GXepwhOEs/jji5T8uSC9LoD9BpzeaBXBdqxC6V1g6NLcHOtm1zrgSuKktcbfLhgpRYjtGXByWZ96d0gEClpU11vY0Nm84cvmKFDUq4RlnJykRGpJvSwENDz0n8+GxOSbvrZL7RzuAxVx4mJb1Q3B3XznI6HiHjND2JFX9kCSf7kJLcEf01PvQWQ2h2SQVq8sNbY4UBiMFt6drAsT4Y7Mnxyy1FN9TxyVf6Eg== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: jzEQFCzWHbdwDVZ/+PnR3WRKFhY+FW0GXIbmSWDIWvpRPEqwedqcpUkQUXGl6jOQnTAaHsX2AYXtwMcf5+7qvz7dToaiWLcpYP0P5Tf8+yUMg7yIgRSLEP/cCTUCJKvDrqMrX4uDNn/ngE8NI6lHzdWLAn20Lw9j1cFAHCJ/UzQikZnA/Vv46VMTzrWv8nzANVcZYbg84Z3uZ44gUC5Ecti7Lp/O+HiKBzitJXTMZE338XD+QBfuK9udFdW9k+mLmwJunYlvtXZUN+y6aLpfWqR0cXPEcOTvRejWWhbc/P+LbPtgaknXnv33RdLNoDpxtpm6+byn0o9oBmpQ2CIgBTUbVB/FrWYOLZvnedtM5KehpUQgKBW5b8byotlQ6HLW0iF4WWiSYkpxJg6levjV20P/flnFt1MdsKleSlHKNUc8JTKyTYj3006hRTaVgSE6NNF5MN5yWWX6e1g7pM+4tOZc25QV8vjAI186G+M5AMvIGZob1NSmEZ1IN+xIJW934jvj/AQeIK6VKSzIHhtW4j8kZcKyhVRL/N2o8emkA7LDWdKugg9WGGKZK5NsXVYg3A8yMSfJJNLaqYyZTI5ddE/L+My/F24SEs25sB9LvlcWgkt/I+NWysqnoajZH9wmW42t4bA8IUd+1mfdEF2zSfi8KdTsajXtSkFyTuPEr5tiGfCeuzgUS6e4136LYWUJ3eeLz5w/nRg3jR9os73LLHymqebfugm0gYG80ZrcD7Aq4Blh+bl8LNicmVqwfXz2BKr4U1D2DpCSWVfmi0pesWb7i6k+GPVfxFxz8zSw9IRFBNWg/B3w+NrwbtZEafvqHLL9HFO9p7tPCsOTCeSXeibGcfdTcRU5G7fm3dmDEfxjr1S6m0FrmEFgxGEVwh58XjZfQ1wYGMe//K/EZQDZZeQKw71NNrhlXVQMZHefKkURl5dU9xfdwU7mwOVC8OTQtE8vPsRnOmr5wtsQtkrxJu/UHHT0rYFE8ZyjxfdcQQYusocCGmKTJRzwJrCXkW92RxpriNeAHMIo8UnUDE5ZJmPlj9R3f9GidQG4ICB5CXjJLXnuq16PVKeC7ui33/QCNrKOFbeV7vZOnMlmKX+cqn1XOwZecv/YzK31yr8Xa7XDRNBW280JVcOWrzX73DygrmLJ4gKDftzdWILkOQjcfFniaEqtza0CPZz73GS5vCumTmQP/BxukGXvQNir2+2PiC6hbDZEAMcEH9HyWUuKrurBSO/r2FjW76WghMVUuVJhnQOk68rrOs3O00d/7mL6/Ym5rTQ1fL9ibdgQ7hs/hHmy71Yz1ww1scy/3HLtZ+ktuFoSCNPYBEdLE87eMGd7/R28rXB/9gdSkHJx6eKKBqICqCM/OTUqSAqHC5oAGXgsFZyjcq+WyZ08CUBGkGcEnTgWg4ux8Pr5yLtFF//frhxVzd+bEFV8vU5hr4/9k+h9fV8vJn7fFDWaU0jOTaxtFSeLYAiDXi6aZxlXO16kNLoqFwbhHRNnaDmCe4T6qBznEl57/hlBHgxHh8pVdtY9RTbHoYBFYMMRS9v2ZOwxyvWPAIGtoxms0hTdHfBiIF9DmDtl29oJmk1yP8SHoQ1J X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: cfc9d6cb-b1ab-4b0f-996f-08dbdfe671c7 X-MS-Exchange-CrossTenant-AuthSource: DM8PR10MB5416.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2023 23:08:24.9816 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Y8dd89tuqjYCRo/zdixBlJ5x3zaCTKKY0bW59zaMq39PL84wJTjjaG+CNryW11PjCujlld9cq8myk7PU1YAIuxGq30l+WoPKpQ+VQwIylmU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB7010 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-07_13,2023-11-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311070189 X-Proofpoint-GUID: xYDt_49QsbCv8Qq5k0yBXTMpnqtVplvY X-Proofpoint-ORIG-GUID: xYDt_49QsbCv8Qq5k0yBXTMpnqtVplvY Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 07 Nov 2023 15:10:06 -0800 (PST) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781948605051274219 X-GMAIL-MSGID: 1781948605051274219 |
Series |
Make the kernel preemptible
|
|
Commit Message
Ankur Arora
Nov. 7, 2023, 11:07 p.m. UTC
Rudimentary script to remove the straight-forward subset of
cond_resched() and allies:
1) if (need_resched())
cond_resched()
2) expression*;
cond_resched(); /* or in the reverse order */
3) if (expression)
statement
cond_resched(); /* or in the reverse order */
The last two patterns depend on the control flow level to ensure
that the complex cond_resched() patterns (ex. conditioned ones)
are left alone and we only pick up ones which are only minimally
related the neighbouring code.
Cc: Julia Lawall <Julia.Lawall@inria.fr>
Cc: Nicolas Palix <nicolas.palix@imag.fr>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
scripts/coccinelle/api/cond_resched.cocci | 53 +++++++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 scripts/coccinelle/api/cond_resched.cocci
Comments
On Tue, 7 Nov 2023, Ankur Arora wrote: > Rudimentary script to remove the straight-forward subset of > cond_resched() and allies: > > 1) if (need_resched()) > cond_resched() > > 2) expression*; > cond_resched(); /* or in the reverse order */ > > 3) if (expression) > statement > cond_resched(); /* or in the reverse order */ > > The last two patterns depend on the control flow level to ensure > that the complex cond_resched() patterns (ex. conditioned ones) > are left alone and we only pick up ones which are only minimally > related the neighbouring code. > > Cc: Julia Lawall <Julia.Lawall@inria.fr> > Cc: Nicolas Palix <nicolas.palix@imag.fr> > Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> > --- > scripts/coccinelle/api/cond_resched.cocci | 53 +++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 scripts/coccinelle/api/cond_resched.cocci > > diff --git a/scripts/coccinelle/api/cond_resched.cocci b/scripts/coccinelle/api/cond_resched.cocci > new file mode 100644 > index 000000000000..bf43768a8f8c > --- /dev/null > +++ b/scripts/coccinelle/api/cond_resched.cocci > @@ -0,0 +1,53 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/// Remove naked cond_resched() statements > +/// > +//# Remove cond_resched() statements when: > +//# - executing at the same control flow level as the previous or the > +//# next statement (this lets us avoid complicated conditionals in > +//# the neighbourhood.) > +//# - they are of the form "if (need_resched()) cond_resched()" which > +//# is always safe. > +//# > +//# Coccinelle generally takes care of comments in the immediate neighbourhood > +//# but might need to handle other comments alluding to rescheduling. > +//# > +virtual patch > +virtual context > + > +@ r1 @ > +identifier r; > +@@ > + > +( > + r = cond_resched(); > +| > +-if (need_resched()) > +- cond_resched(); > +) This rule doesn't make sense. The first branch of the disjunction will never match a a place where the second branch matches. Anyway, in the second branch there is no assignment, so I don't see what the first branch is protecting against. The disjunction is just useless. Whether it is there or or whether only the second brancha is there, doesn't have any impact on the result. > + > +@ r2 @ > +expression E; > +statement S,T; > +@@ > +( > + E; > +| > + if (E) S This case is not needed. It will be matched by the next case. > +| > + if (E) S else T > +| > +) > +-cond_resched(); > + > +@ r3 @ > +expression E; > +statement S,T; > +@@ > +-cond_resched(); > +( > + E; > +| > + if (E) S As above. > +| > + if (E) S else T > +) I have the impression that you are trying to retain some cond_rescheds. Could you send an example of one that you are trying to keep? Overall, the above rules seem a bit ad hoc. You may be keeping some cases you don't want to, or removing some cases that you want to keep. Of course, if you are confident that the job is done with this semantic patch as it is, then that's fine too. julia
Julia Lawall <julia.lawall@inria.fr> writes: > On Tue, 7 Nov 2023, Ankur Arora wrote: > >> Rudimentary script to remove the straight-forward subset of >> cond_resched() and allies: >> >> 1) if (need_resched()) >> cond_resched() >> >> 2) expression*; >> cond_resched(); /* or in the reverse order */ >> >> 3) if (expression) >> statement >> cond_resched(); /* or in the reverse order */ >> >> The last two patterns depend on the control flow level to ensure >> that the complex cond_resched() patterns (ex. conditioned ones) >> are left alone and we only pick up ones which are only minimally >> related the neighbouring code. >> >> Cc: Julia Lawall <Julia.Lawall@inria.fr> >> Cc: Nicolas Palix <nicolas.palix@imag.fr> >> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> >> --- >> scripts/coccinelle/api/cond_resched.cocci | 53 +++++++++++++++++++++++ >> 1 file changed, 53 insertions(+) >> create mode 100644 scripts/coccinelle/api/cond_resched.cocci >> >> diff --git a/scripts/coccinelle/api/cond_resched.cocci b/scripts/coccinelle/api/cond_resched.cocci >> new file mode 100644 >> index 000000000000..bf43768a8f8c >> --- /dev/null >> +++ b/scripts/coccinelle/api/cond_resched.cocci >> @@ -0,0 +1,53 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/// Remove naked cond_resched() statements >> +/// >> +//# Remove cond_resched() statements when: >> +//# - executing at the same control flow level as the previous or the >> +//# next statement (this lets us avoid complicated conditionals in >> +//# the neighbourhood.) >> +//# - they are of the form "if (need_resched()) cond_resched()" which >> +//# is always safe. >> +//# >> +//# Coccinelle generally takes care of comments in the immediate neighbourhood >> +//# but might need to handle other comments alluding to rescheduling. >> +//# >> +virtual patch >> +virtual context >> + >> +@ r1 @ >> +identifier r; >> +@@ >> + >> +( >> + r = cond_resched(); >> +| >> +-if (need_resched()) >> +- cond_resched(); >> +) > > This rule doesn't make sense. The first branch of the disjunction will > never match a a place where the second branch matches. Anyway, in the > second branch there is no assignment, so I don't see what the first branch > is protecting against. > > The disjunction is just useless. Whether it is there or or whether only > the second brancha is there, doesn't have any impact on the result. > >> + >> +@ r2 @ >> +expression E; >> +statement S,T; >> +@@ >> +( >> + E; >> +| >> + if (E) S > > This case is not needed. It will be matched by the next case. > >> +| >> + if (E) S else T >> +| >> +) >> +-cond_resched(); >> + >> +@ r3 @ >> +expression E; >> +statement S,T; >> +@@ >> +-cond_resched(); >> +( >> + E; >> +| >> + if (E) S > > As above. > >> +| >> + if (E) S else T >> +) > > I have the impression that you are trying to retain some cond_rescheds. > Could you send an example of one that you are trying to keep? Overall, > the above rules seem a bit ad hoc. You may be keeping some cases you > don't want to, or removing some cases that you want to keep. Right. I was trying to ensure that the script only handled the cases that didn't have any "interesting" connections to the surrounding code. Just to give you an example of the kind of constructs that I wanted to avoid: mm/memoy.c::zap_pmd_range(): if (addr != next) pmd--; } while (pmd++, cond_resched(), addr != end); mm/backing-dev.c::cleanup_offline_cgwbs_workfn() while (cleanup_offline_cgwb(wb)) cond_resched(); while (cleanup_offline_cgwb(wb)) cond_resched(); But from a quick check the simplest coccinelle script does a much better job than my overly complex (and incorrect) one: @r1@ @@ - cond_resched(); It avoids the first one. And transforms the second to: while (cleanup_offline_cgwb(wb)) {} which is exactly what I wanted. > Of course, if you are confident that the job is done with this semantic > patch as it is, then that's fine too. Not at all. Thanks for pointing out the mistakes. -- ankur
On Wed, 8 Nov 2023, Ankur Arora wrote: > > Julia Lawall <julia.lawall@inria.fr> writes: > > > On Tue, 7 Nov 2023, Ankur Arora wrote: > > > >> Rudimentary script to remove the straight-forward subset of > >> cond_resched() and allies: > >> > >> 1) if (need_resched()) > >> cond_resched() > >> > >> 2) expression*; > >> cond_resched(); /* or in the reverse order */ > >> > >> 3) if (expression) > >> statement > >> cond_resched(); /* or in the reverse order */ > >> > >> The last two patterns depend on the control flow level to ensure > >> that the complex cond_resched() patterns (ex. conditioned ones) > >> are left alone and we only pick up ones which are only minimally > >> related the neighbouring code. > >> > >> Cc: Julia Lawall <Julia.Lawall@inria.fr> > >> Cc: Nicolas Palix <nicolas.palix@imag.fr> > >> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> > >> --- > >> scripts/coccinelle/api/cond_resched.cocci | 53 +++++++++++++++++++++++ > >> 1 file changed, 53 insertions(+) > >> create mode 100644 scripts/coccinelle/api/cond_resched.cocci > >> > >> diff --git a/scripts/coccinelle/api/cond_resched.cocci b/scripts/coccinelle/api/cond_resched.cocci > >> new file mode 100644 > >> index 000000000000..bf43768a8f8c > >> --- /dev/null > >> +++ b/scripts/coccinelle/api/cond_resched.cocci > >> @@ -0,0 +1,53 @@ > >> +// SPDX-License-Identifier: GPL-2.0-only > >> +/// Remove naked cond_resched() statements > >> +/// > >> +//# Remove cond_resched() statements when: > >> +//# - executing at the same control flow level as the previous or the > >> +//# next statement (this lets us avoid complicated conditionals in > >> +//# the neighbourhood.) > >> +//# - they are of the form "if (need_resched()) cond_resched()" which > >> +//# is always safe. > >> +//# > >> +//# Coccinelle generally takes care of comments in the immediate neighbourhood > >> +//# but might need to handle other comments alluding to rescheduling. > >> +//# > >> +virtual patch > >> +virtual context > >> + > >> +@ r1 @ > >> +identifier r; > >> +@@ > >> + > >> +( > >> + r = cond_resched(); > >> +| > >> +-if (need_resched()) > >> +- cond_resched(); > >> +) > > > > This rule doesn't make sense. The first branch of the disjunction will > > never match a a place where the second branch matches. Anyway, in the > > second branch there is no assignment, so I don't see what the first branch > > is protecting against. > > > > The disjunction is just useless. Whether it is there or or whether only > > the second brancha is there, doesn't have any impact on the result. > > > >> + > >> +@ r2 @ > >> +expression E; > >> +statement S,T; > >> +@@ > >> +( > >> + E; > >> +| > >> + if (E) S > > > > This case is not needed. It will be matched by the next case. > > > >> +| > >> + if (E) S else T > >> +| > >> +) > >> +-cond_resched(); > >> + > >> +@ r3 @ > >> +expression E; > >> +statement S,T; > >> +@@ > >> +-cond_resched(); > >> +( > >> + E; > >> +| > >> + if (E) S > > > > As above. > > > >> +| > >> + if (E) S else T > >> +) > > > > I have the impression that you are trying to retain some cond_rescheds. > > Could you send an example of one that you are trying to keep? Overall, > > the above rules seem a bit ad hoc. You may be keeping some cases you > > don't want to, or removing some cases that you want to keep. > > Right. I was trying to ensure that the script only handled the cases > that didn't have any "interesting" connections to the surrounding code. > > Just to give you an example of the kind of constructs that I wanted > to avoid: > > mm/memoy.c::zap_pmd_range(): > > if (addr != next) > pmd--; > } while (pmd++, cond_resched(), addr != end); > > mm/backing-dev.c::cleanup_offline_cgwbs_workfn() > > while (cleanup_offline_cgwb(wb)) > cond_resched(); > > > while (cleanup_offline_cgwb(wb)) > cond_resched(); > > But from a quick check the simplest coccinelle script does a much > better job than my overly complex (and incorrect) one: > > @r1@ > @@ > - cond_resched(); > > It avoids the first one. And transforms the second to: > > while (cleanup_offline_cgwb(wb)) > {} > > which is exactly what I wanted. Perfect! It could be good to run both scripts and compare the results. julia > > > Of course, if you are confident that the job is done with this semantic > > patch as it is, then that's fine too. > > Not at all. Thanks for pointing out the mistakes. > > > > -- > ankur >
On Tue, Nov 07, 2023 at 03:07:53PM -0800, Ankur Arora wrote: > Rudimentary script to remove the straight-forward subset of > cond_resched() and allies: > > 1) if (need_resched()) > cond_resched() > > 2) expression*; > cond_resched(); /* or in the reverse order */ > > 3) if (expression) > statement > cond_resched(); /* or in the reverse order */ > > The last two patterns depend on the control flow level to ensure > that the complex cond_resched() patterns (ex. conditioned ones) > are left alone and we only pick up ones which are only minimally > related the neighbouring code. This series looks to get rid of stall warnings for long in-kernel preempt-enabled code paths, which is of course a very good thing. But removing all of the cond_resched() calls can actually increase scheduling latency compared to the current CONFIG_PREEMPT_NONE=y state, correct? If so, it would be good to take a measured approach. For example, it is clear that a loop that does a cond_resched() every (say) ten jiffies can remove that cond_resched() without penalty, at least in kernels built with either CONFIG_NO_HZ_FULL=n or CONFIG_PREEMPT=y. But this is not so clear for a loop that does a cond_resched() every (say) ten microseconds. Or am I missing something here? Thanx, Paul > Cc: Julia Lawall <Julia.Lawall@inria.fr> > Cc: Nicolas Palix <nicolas.palix@imag.fr> > Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com> > --- > scripts/coccinelle/api/cond_resched.cocci | 53 +++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 scripts/coccinelle/api/cond_resched.cocci > > diff --git a/scripts/coccinelle/api/cond_resched.cocci b/scripts/coccinelle/api/cond_resched.cocci > new file mode 100644 > index 000000000000..bf43768a8f8c > --- /dev/null > +++ b/scripts/coccinelle/api/cond_resched.cocci > @@ -0,0 +1,53 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/// Remove naked cond_resched() statements > +/// > +//# Remove cond_resched() statements when: > +//# - executing at the same control flow level as the previous or the > +//# next statement (this lets us avoid complicated conditionals in > +//# the neighbourhood.) > +//# - they are of the form "if (need_resched()) cond_resched()" which > +//# is always safe. > +//# > +//# Coccinelle generally takes care of comments in the immediate neighbourhood > +//# but might need to handle other comments alluding to rescheduling. > +//# > +virtual patch > +virtual context > + > +@ r1 @ > +identifier r; > +@@ > + > +( > + r = cond_resched(); > +| > +-if (need_resched()) > +- cond_resched(); > +) > + > +@ r2 @ > +expression E; > +statement S,T; > +@@ > +( > + E; > +| > + if (E) S > +| > + if (E) S else T > +| > +) > +-cond_resched(); > + > +@ r3 @ > +expression E; > +statement S,T; > +@@ > +-cond_resched(); > +( > + E; > +| > + if (E) S > +| > + if (E) S else T > +) > -- > 2.31.1 >
Paul E. McKenney <paulmck@kernel.org> writes: > On Tue, Nov 07, 2023 at 03:07:53PM -0800, Ankur Arora wrote: >> Rudimentary script to remove the straight-forward subset of >> cond_resched() and allies: >> >> 1) if (need_resched()) >> cond_resched() >> >> 2) expression*; >> cond_resched(); /* or in the reverse order */ >> >> 3) if (expression) >> statement >> cond_resched(); /* or in the reverse order */ >> >> The last two patterns depend on the control flow level to ensure >> that the complex cond_resched() patterns (ex. conditioned ones) >> are left alone and we only pick up ones which are only minimally >> related the neighbouring code. > > This series looks to get rid of stall warnings for long in-kernel > preempt-enabled code paths, which is of course a very good thing. > But removing all of the cond_resched() calls can actually increase > scheduling latency compared to the current CONFIG_PREEMPT_NONE=y state, > correct? Not necessarily. If TIF_NEED_RESCHED_LAZY is set, then we let the current task finish before preempting. If that task runs for arbitrarily long (what Thomas calls the hog problem) -- currently we allow them to run for upto one extra tick (which might shorten/become a tunable.) If TIF_NEED_RESCHED is set, then it gets folded the same it does now and preemption happens at the next safe preemption point. So, I guess the scheduling latency would always be bounded but how much latency a task would incur would be scheduler policy dependent. This is early days, so the policy (or really the rest of it) isn't set in stone but having two levels of preemption -- immediate and deferred -- does seem to give the scheduler greater freedom of policy. Btw, are you concerned about the scheduling latencies in general or the scheduling latency of a particular set of tasks? > If so, it would be good to take a measured approach. For example, it > is clear that a loop that does a cond_resched() every (say) ten jiffies > can remove that cond_resched() without penalty, at least in kernels built > with either CONFIG_NO_HZ_FULL=n or CONFIG_PREEMPT=y. But this is not so > clear for a loop that does a cond_resched() every (say) ten microseconds. True. Though both of those loops sound bad :). Yeah, and as we were discussing offlist, the question is the comparative density of preempt_dec_and_test() is true vs calls to cond_resched(). And if they are similar then we could replace cond_resched() quiescence reporting with ones in preempt_enable() (as you mention elsewhere in the thread.) Thanks -- ankur
On Mon, Nov 20, 2023 at 09:16:19PM -0800, Ankur Arora wrote: > > Paul E. McKenney <paulmck@kernel.org> writes: > > > On Tue, Nov 07, 2023 at 03:07:53PM -0800, Ankur Arora wrote: > >> Rudimentary script to remove the straight-forward subset of > >> cond_resched() and allies: > >> > >> 1) if (need_resched()) > >> cond_resched() > >> > >> 2) expression*; > >> cond_resched(); /* or in the reverse order */ > >> > >> 3) if (expression) > >> statement > >> cond_resched(); /* or in the reverse order */ > >> > >> The last two patterns depend on the control flow level to ensure > >> that the complex cond_resched() patterns (ex. conditioned ones) > >> are left alone and we only pick up ones which are only minimally > >> related the neighbouring code. > > > > This series looks to get rid of stall warnings for long in-kernel > > preempt-enabled code paths, which is of course a very good thing. > > But removing all of the cond_resched() calls can actually increase > > scheduling latency compared to the current CONFIG_PREEMPT_NONE=y state, > > correct? > > Not necessarily. > > If TIF_NEED_RESCHED_LAZY is set, then we let the current task finish > before preempting. If that task runs for arbitrarily long (what Thomas > calls the hog problem) -- currently we allow them to run for upto one > extra tick (which might shorten/become a tunable.) Agreed, and that is the easy case. But getting rid of the cond_resched() calls really can increase scheduling latency of this patchset compared to status-quo mainline. > If TIF_NEED_RESCHED is set, then it gets folded the same it does now > and preemption happens at the next safe preemption point. > > So, I guess the scheduling latency would always be bounded but how much > latency a task would incur would be scheduler policy dependent. > > This is early days, so the policy (or really the rest of it) isn't set > in stone but having two levels of preemption -- immediate and > deferred -- does seem to give the scheduler greater freedom of policy. "Give the scheduler freedom!" is a wonderful slogan, but not necessarily a useful one-size-fits-all design principle. The scheduler does not and cannot know everything, after all. > Btw, are you concerned about the scheduling latencies in general or the > scheduling latency of a particular set of tasks? There are a lot of workloads out there with a lot of objective functions and constraints, but it is safe to say that both will be important, as will other things, depending on the workload. But you knew that already, right? ;-) > > If so, it would be good to take a measured approach. For example, it > > is clear that a loop that does a cond_resched() every (say) ten jiffies > > can remove that cond_resched() without penalty, at least in kernels built > > with either CONFIG_NO_HZ_FULL=n or CONFIG_PREEMPT=y. But this is not so > > clear for a loop that does a cond_resched() every (say) ten microseconds. > > True. Though both of those loops sound bad :). Yes, but do they sound bad enough to be useful in the real world? ;-) > Yeah, and as we were discussing offlist, the question is the comparative > density of preempt_dec_and_test() is true vs calls to cond_resched(). > > And if they are similar then we could replace cond_resched() quiescence > reporting with ones in preempt_enable() (as you mention elsewhere in the > thread.) Here is hoping that something like that can help. I am quite happy with the thought of reducing the number of cond_resched() invocations, but not at the expense of the Linux kernel failing to do its job. Thanx, Paul
diff --git a/scripts/coccinelle/api/cond_resched.cocci b/scripts/coccinelle/api/cond_resched.cocci new file mode 100644 index 000000000000..bf43768a8f8c --- /dev/null +++ b/scripts/coccinelle/api/cond_resched.cocci @@ -0,0 +1,53 @@ +// SPDX-License-Identifier: GPL-2.0-only +/// Remove naked cond_resched() statements +/// +//# Remove cond_resched() statements when: +//# - executing at the same control flow level as the previous or the +//# next statement (this lets us avoid complicated conditionals in +//# the neighbourhood.) +//# - they are of the form "if (need_resched()) cond_resched()" which +//# is always safe. +//# +//# Coccinelle generally takes care of comments in the immediate neighbourhood +//# but might need to handle other comments alluding to rescheduling. +//# +virtual patch +virtual context + +@ r1 @ +identifier r; +@@ + +( + r = cond_resched(); +| +-if (need_resched()) +- cond_resched(); +) + +@ r2 @ +expression E; +statement S,T; +@@ +( + E; +| + if (E) S +| + if (E) S else T +| +) +-cond_resched(); + +@ r3 @ +expression E; +statement S,T; +@@ +-cond_resched(); +( + E; +| + if (E) S +| + if (E) S else T +)