Message ID | 20231107215742.363031-42-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 k11csp542795vqo; Tue, 7 Nov 2023 14:04:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IFksvSEUO+2CM+X31EeG49KCryIC4zWmMuuKcQg2A2ujAdLTePqmiN49Lo+q5fRxJD5IhRv X-Received: by 2002:a17:903:18f:b0:1cc:fc8:5be1 with SMTP id z15-20020a170903018f00b001cc0fc85be1mr413334plg.1.1699394660042; Tue, 07 Nov 2023 14:04:20 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1699394660; cv=pass; d=google.com; s=arc-20160816; b=st0i8sd8NDE5IicKDO+dET7IKX/JQAx3BmGSU9m+AXY46IVVOdDDqUfvF7sOdFFpUO 56BD4/VkISPfr0FK3KKDttuzHja4iYMP1FcXpcn6JLbjY/fRhR3o1sY7hAxooxYvmaut z534gaAnRwyCilyfOUXaCrbU2ObU4IOvpz1fq8yYi8EsitW+ThqMQHRX+HsD2Z3bJ/t/ X9opPQfjMVmcqySZl4vZzOvd1YfY3/8U9zLxMdjxKyP6Ewa7Eqf9FNUdK2/G0IVSwYWL 0XuKY7z5zeb3mM2YvFmFiptolkzjp6KQeyQdr08NMNNsB6W63liimHMdXrb22/2JlMSB aXdA== 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=PzHw82oEkjWSM8GhCZuzoOhLZoIhhNSDnnxsu9vLv6o=; fh=nHnEAWNp+qNKUfhTYdiVYwv41cALFixOy2SlfWaTsrM=; b=znydOvWbytblgas0r7OAPscoudRkk2t6sn4ni10APc3DLzp8xxsGsv1nd4Qutwlc9i U7cqygFBej2gprfX4+TSUZX/zOVMMCdeMlhDbo1/dYBtEf7YsQQrJSwz7TMs4mKKr4Gl v4TXEAf4PQ1eViW/BqcugwSTKO+P0JuiT9NlD6YD3b66HrSr8Klv/MkSV3ZZ4whVr3Qw DO20TUSOG6fpyJc1Y0X3OpasBFRqDH1m9tygbah/m8MM+Aa9zod1MNUEZx+3t+7vMx76 yDiX/XY2K0xkhFfZbP7UBW8EC0UsWy1MsHfu465ETsIsn++Kz8ue3zm2rloDzsPSV6ZM XWPg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=uBCx9poG; dkim=pass header.i=@oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=b4B0rJqd; 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 23.128.96.37 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 snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id be8-20020a170902aa0800b001cc0fdbea2asi668258plb.142.2023.11.07.14.04.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 14:04:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-03-30 header.b=uBCx9poG; dkim=pass header.i=@oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=b4B0rJqd; 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 23.128.96.37 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 snail.vger.email (Postfix) with ESMTP id DB78D83382AC; Tue, 7 Nov 2023 14:04:18 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344132AbjKGWEI (ORCPT <rfc822;lhua1029@gmail.com> + 32 others); Tue, 7 Nov 2023 17:04:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235341AbjKGWD3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Nov 2023 17:03:29 -0500 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6AAB81723 for <linux-kernel@vger.kernel.org>; Tue, 7 Nov 2023 14:00:48 -0800 (PST) Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3A7LK255022959; Tue, 7 Nov 2023 21:59:51 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=PzHw82oEkjWSM8GhCZuzoOhLZoIhhNSDnnxsu9vLv6o=; b=uBCx9poGHhF6SKD85mK2kEM6et/jSfcOa3dKkyUXNA973zwpyxa2DStX3OsqFOfezFVr 6GTMZLJiYw32yEfAVMrWIvSPv9lqeYV5uRhCXP8DQ07QkHCTMvvtGG7fzhVgrg7dtVLj mEaroCcdMmEb6LofBQpHBn0HVR6UwItRhz4uNNmhOg66+jzKA6g8D6tRtltjBS6r+A9m av/itYG8dPz5xTu/hcOtL6tT36Q377ewvWA2XR4StFkGmkaq/aon7WTEydcFzVkEwsr5 fq2nOZGLMdS2M8ZpDsZUuWroLAg+cLku5MnMzZ/coCx1oGrAQcLqzuHjub5+ieCTY6z5 qA== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3u7w2002j0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Nov 2023 21:59:51 +0000 Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 3A7LIwbU000509; Tue, 7 Nov 2023 21:59:50 GMT Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam04lp2040.outbound.protection.outlook.com [104.47.73.40]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3u7w1wsmf2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Nov 2023 21:59:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DCpYolXEfBN14K5cCahkwXkpgCCx1cgjaDT82wofFyJx9ueUKemzbapGqPj20AziBzFelfEEdRpPL93vSpsuQ317h93gw60sw1Bqc5L51VcoBvtcmX59WbH1U6ERIeYtKeRddpuPXMPrV3cmiDF5/5SO+JeIx5G6arDjakJSTyqLPr4j+vOferA58cSPWSi2HL+3eChoG/25a1z1vGJRv4oe9n/19bpEuBXQzfee4hbIaw7MvGlouNosh4J5gTfEaCpu641+f9mwdsX9CSEcyE5mCn5AUwKFHpEzK9HDJGMWB89k//WwIYLELhRTQ3dALPQ2TZjaaTgDmNkrpgreaQ== 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=PzHw82oEkjWSM8GhCZuzoOhLZoIhhNSDnnxsu9vLv6o=; b=ntFrAitrybSGSqNBUewhVP1XuOn/FOrw8lonGpni6OgSGSx2bbQ9ctrUP4x5AZwlGjwWgxkAfXE6sgvaMBr61nTJ0aznT4a9NKhy2L2r03rF15CRt1OeX8cUQ0r3Qdqfplt+qnnd1Raab1vIJKrSyV2eLB56ltOPej9xaG/lCFOaxHtjOXuTPCVKmHrcqmo18te3vpzCXjv8uX9d5pGJaOhYfyzYAe3E6Zv5HI6L28S3xHZvLLI0Ose75POV0AiL0hHDhgv/gP5W2FkqR4QgkLr6pMn6JUTgpJvsrlAEjZq0aJt1pSugPfrWE7EZdigIP+ttoHxcQuMb53EZKVtkZg== 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=PzHw82oEkjWSM8GhCZuzoOhLZoIhhNSDnnxsu9vLv6o=; b=b4B0rJqdH7d+pBBB2J3g4rH7ux+22YzLFcyzjWhpL8AgjJrVxVrQDmZeQsZ1+0rpTqF19wNTYFPRMWofImzcKpYf4qv0ImZkP5NpSO6/eY2I9Zi4rfa3D/NdtWa01adi+HdfxlyETn5hSJtjeqMo4DqfR1dNvNCTzKsoyzAEJ5g= Received: from CO6PR10MB5409.namprd10.prod.outlook.com (2603:10b6:5:357::14) by CY5PR10MB6141.namprd10.prod.outlook.com (2603:10b6:930:37::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.28; Tue, 7 Nov 2023 21:59:47 +0000 Received: from CO6PR10MB5409.namprd10.prod.outlook.com ([fe80::1ce3:4a8c:4c99:acea]) by CO6PR10MB5409.namprd10.prod.outlook.com ([fe80::1ce3:4a8c:4c99:acea%7]) with mapi id 15.20.6954.028; Tue, 7 Nov 2023 21:59:47 +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> Subject: [RFC PATCH 41/86] sched: handle resched policy in resched_curr() Date: Tue, 7 Nov 2023 13:57:27 -0800 Message-Id: <20231107215742.363031-42-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: MW4PR04CA0309.namprd04.prod.outlook.com (2603:10b6:303:82::14) To CO6PR10MB5409.namprd10.prod.outlook.com (2603:10b6:5:357::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CO6PR10MB5409:EE_|CY5PR10MB6141:EE_ X-MS-Office365-Filtering-Correlation-Id: 57b602de-ef27-49fa-2b7e-08dbdfdcdb63 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: alIjP+A/j3H7tkRjSsPJGNRMv35Dais9mxh2/ds8jKdXpZu4z1ZMd8Xftr/zgNcEY+4u5cGOA2nGoRsztzXZAz8z71RT93d5SA6W+t+32IoeK70nTIpLZxW+G3bFRMcJbJXf6wygrxxG45Z0QBDj1nYLhaNtH/dnNVZgaPGXBBwSjNREkpSsynO5u2jRxAU+VwiX++1ztHXBBXS2xGNkaFnBPzv1zEAlrB624YUMqhy8Wj7Gl0U+s6dIVFVCrlN+bH/cFREFdI5hmEin6RPxw3xNLUORhkhwWXJo1S7IXZri1mtAQ/aPmI0Snu9+gGB1n+cOKpGSqXAzV9Jogfq9gnkxnfK2mJvzd/ZIqHaMeKYgiokWlC01JnsEmgN0IB+mkK7XUYYxs2IhUbt6VPHQOzZyyceYVyb9cuJISBltPZB8K6dA5cCtZc3OSibfAPk4boEMsoL+xG7UfpzfTb5pR7xQ+9ERGejW8cDaKTbIg4F7S4u/3aXFtoQpbyTkcXn0GjmggYU03Sak16pHGpssEneJrSOeoEHpUMXtOjFmQIZQKEG1tVkoi1Qh93bPCD5t X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO6PR10MB5409.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(346002)(396003)(376002)(39860400002)(136003)(366004)(230922051799003)(186009)(1800799009)(451199024)(64100799003)(6506007)(86362001)(103116003)(8676002)(478600001)(8936002)(6486002)(4326008)(6666004)(38100700002)(1076003)(5660300002)(36756003)(6512007)(66476007)(6916009)(66946007)(66556008)(316002)(2616005)(7416002)(107886003)(7406005)(2906002)(26005)(83380400001)(41300700001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: JoCkS36sxHBJKGvP0/REZrZv+iEt7Zhq/XXRQDpM4sxubzqe4PA/624H1lRFhcCuMG4yNrq8VncbHqQzna4PqYzrbwUL4i2jxInUP57H19Z5ccbysDpJzIPo0gDlJ4VDRWtlfnqQVlvIq/FOhSq924KtHiOUNQq+quTT/LMik4B7JE9T45IoDTOU/wdp6VwWLP1ObBw9SK9tM2KRYmHu3ydrelqz5gOxrk2JQ8BxWlYL8hFC9gq50f9/obXLq3NeYZ7AocP0lb35TSm/l1U1jKbmH+Ir0xG/kkGAxwUKQW8X5XjxIhNOBRootjTxOP7sjbsVY+j4Nwf3sQT9XrURyVwBUc8V/YJg4bV4TFOzx0FVrsen1aA3lX9Vy9De0THEBztz8rUxjr7vq9EPwsWMm+Tkm8j8D/3g6/0L7xE+rUGiuoXxv90dVBqpjo0uX274v1z6HjIUsEpF8rkzwEhLVECXnnZDARzPZ2kRrska6Yew7mC22p3O/rvO1EDPFsrXQq37Z0OjPE3PnFbNB75VICn1MukPmw1PcKIzOgDmEw2r+aZhpmEE+pM+OntNcg9RBLejUm1N6wI5r37sEnHmSyrEnOleh1qWH2+k5SNwUpviG5oDHQmWvdBpcSjneHCpxk1+/XAMDAAveVZPu95XZEE1rQI+RLtqgmuB3ZCv4HA9fEeK5+MERNeRjV51oGPnijtsHsEIKxzxTTlxSGn8WO8PqtJSzKn+K3YpEIZmkzkPv9yukiVwysx2DGFhsYosKZJRUPNNGYPxSzu8vQUOt4XTWZmsZpm/Cih6oVNPgTjBBGv6N/clHWamGICTXPc5jo7okdvb//Y+Jk8Bhj6RYvjW7dseVhSdttGB3ycSTQEo37HPBYafRHp20ZKAeJDcnIeimkVmhzna/EhYihAgFnu6h8OZ1uQQ7CcWWbZM3NWaOlYc87vFpF+ybGSDbWy5Gb1zQtsrPXUW96CYjxWODIIp/uxd18LoYOb7lZpukn2n7uG4CV6gLfpK5IFvkfP9/iUnVvLEsYt+y3n5AROOtsQ3rEt+Iq4RzeR3glrmENvTqMqydNnFCAb3KolP91h2TEtbolFYePr9shyLC311bbX/DDcGixNFOxz6l3ubU7CVIrApNAXE+kx64nAu+sAP34UNDuZ6ymWuLoQMGrnQuyohsih9VLnhqZNN4+vXNOhaiHQkYiALUlIHUHC54EvvfpVLr774r8OTx0KOgfUvfDng93II6GaQYeyVFdF/NmQ9hjn+pmLu3rdEvhfjb2FRRZl1DPNGVSQ3ZHbZizr8Tm/wRwXkV0iSUbXDHah9kXwztxcuZT224TkbBYtzHua8qWheSkQsefhHq6AmP9Qrzh84H5QM2764Pnam1JQKIsmsSd4QNyUPuL142xiokOQVVhJEwsf7iG9DhJf+MS8xJiY3kUH7HJsaDZIcMcJ4yPl6NX7QFEhA/wxaqr69hzfm+67gMhZ3CC8iduggHiCH6ThSZN+uAPSoxuCD2g2yLtfrJ1fw3FucygI4tHy5aMrvhbRrTNxx7MLAG2afS/MylT+KrqAvhicbiMCvBJw+TLnyQFHmfbk0kpR4eFtF2yUlYY4Aw+BCKV+SQdtB01HdzQ== X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: clOikU/RxyK2qgsFa4b8hgNtIg2a48cn9dqUAbTgr8tlvEovDYNwGWlyCxNeJclL6B/4LYQ3SjxcSv0ZClcjsQFfYDgeHuKThQywPAUvjQxuPX+PP6OZ/UofVEKBNBKoth9EGO/GGP8bYjB+jyXCqTj19ifQi08rY/67V/AQvUn8nm4iVpv9pW6+QvRyjZCWYic8yGTpW/VMcPtpHV4m4FPEcaChdEs1JM/AwylJVAsUwxrIfErjGULVzMRSNy9rZlNJwC3S2HUAMcSQnfznsm0QvyvL0xIXyX8u8f2Ayi5c6B70Fi8zXchhJIr6dA4s7yavPZmyR9At/wB6IK92mEqBTPEvLxdWba+e+DB1V2/LZgurU5zRNQNUILnF+kLUw5FwbI85TsIMH8sEiEzk58Kimek/thn6H2BlogiyIaFDvN/gatWMLj5iIW5wKoXzYgBfncqL+/9icDjbf7R0ZYpBqEDr+8k/MtBGnmUO09ZQBX/Crzlw4/HwKCEAQAUOGcu/Z/VWV4DMX/vYHliRB3JMzFTfInWEfQMQJti2jdaDvcLc6XZdZMxzADUbBGzKtx+pa+8IELCaLoJUqUsPqxLPH0gJ3+IkAtB2O3V2WHnAytX47ft6+kyX4/q17TRieZN3YLCnxpOD0wy5JmkPiAytz2HavXKueJ6pAtygj7MLxgrI2a4qRPCv55514TZqk0Z5bHeVw0XTy9Q1ieb3KEHE0fIQNWG/qu5dBr2tXS9zTorKv5wbj5Hc7IxgmYjCCmf1fgJIcYlmqGhHItEDcr5/YU+3LLBGVYcUwoWr5QJ2g+eR//kgOUWstSSWVCxuSoVswqAHUQYly92iD6DjVtQ3S6BPwt3iwrwnYm8ooL/XbC9VPTYZGPbZBE638SvL+HxILerndjVXo28Be99GLFia5DiPcXr2hDvmrzk8FJkGF9cneuivIWztMMTBnZkxqQm1rAAxqEzjxxI/VWaVu3fVL3f2dc1mMqwKy3x5zAkoZPpLWUDTRV07INoQLpaJGAUNwef+pgIkUYB2yaHeZQ2GC7GeZuTxlGUa1YZp6/7LbCAtZv4CQZE0AISSamG1fdScHeE2L6MU8ez95DkBqjMBGq87FbAyjYIWVNwbJu7mZsT8GJNFTheCpV+rjHdsd5xJUZKWqOALgdo0LpnklKf0QTaQcYwSygB3t6m1t5J7TK3iJmAVnLt9E0jof+r/gn0smsg2DNQ0wVhv8bMT+VVSciOZPa4CRGl6cakbHgJWsEcFM2kmQtcgYXK5tE+6gUWp+xtWS614GAyxKJuvvJbNKahb5th4VsdH7lTkbIkm86bL3F+AnTyqkizk+Dll3x7CTmOW3E0jWe8ZtpU0Xb8QD52TaOKm6zy0De6totr4QVRjEWLCEW282FX3fnQwGlmIn1AXfFBXDJ9k6po+XHLZgSMYjnKS3z3vl6OGKlWXQli9/DEfMkfcRRtZcO15zMHbKJZWUc/TtaEmLv/GfNKWoJRegs0JUf3WtoExfM6G4amR4EHTfFNh8k1/y4vE40d0U3S8w3FeB5+H1qxjOg== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 57b602de-ef27-49fa-2b7e-08dbdfdcdb63 X-MS-Exchange-CrossTenant-AuthSource: CO6PR10MB5409.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2023 21:59:47.0886 (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: aDr67krRKVBku9HxJswQeqUG9JcfPw2W41N+nH7XPFECnvEAT7jpv4jOccccYTzYiKfgariUK3j7ONCDXBqu5JahFqKWFz+mcUFzKMIZ7bI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR10MB6141 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 malwarescore=0 mlxscore=0 suspectscore=0 mlxlogscore=999 adultscore=0 spamscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311070182 X-Proofpoint-ORIG-GUID: tHGkLVpKjcEGtNJ_4RGk7iDp9yAfm-CU X-Proofpoint-GUID: tHGkLVpKjcEGtNJ_4RGk7iDp9yAfm-CU 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 (snail.vger.email [0.0.0.0]); Tue, 07 Nov 2023 14:04:18 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781944454993347711 X-GMAIL-MSGID: 1781944454993347711 |
Series |
Make the kernel preemptible
|
|
Commit Message
Ankur Arora
Nov. 7, 2023, 9:57 p.m. UTC
One of the last ports of call before rescheduling is triggered
is resched_curr().
It's task is to set TIF_NEED_RESCHED and, if running locally,
either fold it in the preempt_count, or send a resched-IPI so
the target CPU folds it in.
To handle TIF_NEED_RESCHED_LAZY -- since the reschedule is not
imminent -- it only needs to set the appropriate bit.
Move all of underlying mechanism in __resched_curr(). And, define
resched_curr() which handles the policy on when we want to set
which need-resched variant.
For now the approach is to run to completion (TIF_NEED_RESCHED_LAZY)
with the following exceptions where we always want to reschedule
at the next preemptible point (TIF_NEED_RESCHED):
- idle: if we are polling in idle, then set_nr_if_polling() will do
the right thing. When not polling, we force TIF_NEED_RESCHED
and send a resched-IPI if needed.
- the target CPU is in userspace: run to completion semantics are
only for kernel tasks
- running under the full preemption model
Originally-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
---
kernel/sched/core.c | 80 +++++++++++++++++++++++++++++++++++++++------
1 file changed, 70 insertions(+), 10 deletions(-)
Comments
On Tue, Nov 07, 2023 at 01:57:27PM -0800, Ankur Arora wrote: > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -1027,13 +1027,13 @@ void wake_up_q(struct wake_q_head *head) > } > > /* > - * resched_curr - mark rq's current task 'to be rescheduled now'. > + * __resched_curr - mark rq's current task 'to be rescheduled'. > * > - * On UP this means the setting of the need_resched flag, on SMP it > - * might also involve a cross-CPU call to trigger the scheduler on > - * the target CPU. > + * On UP this means the setting of the need_resched flag, on SMP, for > + * eager resched it might also involve a cross-CPU call to trigger > + * the scheduler on the target CPU. > */ > -void resched_curr(struct rq *rq) > +void __resched_curr(struct rq *rq, resched_t rs) > { > struct task_struct *curr = rq->curr; > int cpu; > @@ -1046,17 +1046,77 @@ void resched_curr(struct rq *rq) > cpu = cpu_of(rq); > > if (cpu == smp_processor_id()) { > - set_tsk_need_resched(curr, RESCHED_eager); > - set_preempt_need_resched(); > + set_tsk_need_resched(curr, rs); > + if (rs == RESCHED_eager) > + set_preempt_need_resched(); > return; > } > > - if (set_nr_and_not_polling(curr, RESCHED_eager)) > - smp_send_reschedule(cpu); > - else > + if (set_nr_and_not_polling(curr, rs)) { > + if (rs == RESCHED_eager) > + smp_send_reschedule(cpu); I think you just broke things. Not all idle threads have POLLING support, in which case you need that IPI to wake them up, even if it's LAZY. > + } else if (rs == RESCHED_eager) > trace_sched_wake_idle_without_ipi(cpu); > } > > +/* > + * resched_curr - mark rq's current task 'to be rescheduled' eagerly > + * or lazily according to the current policy. > + * > + * Always schedule eagerly, if: > + * > + * - running under full preemption > + * > + * - idle: when not polling (or if we don't have TIF_POLLING_NRFLAG) > + * force TIF_NEED_RESCHED to be set and send a resched IPI. > + * (the polling case has already set TIF_NEED_RESCHED via > + * set_nr_if_polling()). > + * > + * - in userspace: run to completion semantics are only for kernel tasks > + * > + * Otherwise (regardless of priority), run to completion. > + */ > +void resched_curr(struct rq *rq) > +{ > + resched_t rs = RESCHED_lazy; > + int context; > + > + if (IS_ENABLED(CONFIG_PREEMPT) || > + (rq->curr->sched_class == &idle_sched_class)) { > + rs = RESCHED_eager; > + goto resched; > + } > + > + /* > + * We might race with the target CPU while checking its ct_state: > + * > + * 1. The task might have just entered the kernel, but has not yet > + * called user_exit(). We will see stale state (CONTEXT_USER) and > + * send an unnecessary resched-IPI. > + * > + * 2. The user task is through with exit_to_user_mode_loop() but has > + * not yet called user_enter(). > + * > + * We'll see the thread's state as CONTEXT_KERNEL and will try to > + * schedule it lazily. There's obviously nothing that will handle > + * this need-resched bit until the thread enters the kernel next. > + * > + * The scheduler will still do tick accounting, but a potentially > + * higher priority task waited to be scheduled for a user tick, > + * instead of execution time in the kernel. > + */ > + context = ct_state_cpu(cpu_of(rq)); > + if ((context == CONTEXT_USER) || > + (context == CONTEXT_GUEST)) { > + > + rs = RESCHED_eager; > + goto resched; > + } Like said, this simply cannot be. You must not rely on the remote CPU being in some state or not. Also, it's racy, you could observe USER and then it enters KERNEL. > + > +resched: > + __resched_curr(rq, rs); > +} > + > void resched_cpu(int cpu) > { > struct rq *rq = cpu_rq(cpu);
Peter Zijlstra <peterz@infradead.org> writes: > On Tue, Nov 07, 2023 at 01:57:27PM -0800, Ankur Arora wrote: > >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -1027,13 +1027,13 @@ void wake_up_q(struct wake_q_head *head) >> } >> >> /* >> - * resched_curr - mark rq's current task 'to be rescheduled now'. >> + * __resched_curr - mark rq's current task 'to be rescheduled'. >> * >> - * On UP this means the setting of the need_resched flag, on SMP it >> - * might also involve a cross-CPU call to trigger the scheduler on >> - * the target CPU. >> + * On UP this means the setting of the need_resched flag, on SMP, for >> + * eager resched it might also involve a cross-CPU call to trigger >> + * the scheduler on the target CPU. >> */ >> -void resched_curr(struct rq *rq) >> +void __resched_curr(struct rq *rq, resched_t rs) >> { >> struct task_struct *curr = rq->curr; >> int cpu; >> @@ -1046,17 +1046,77 @@ void resched_curr(struct rq *rq) >> cpu = cpu_of(rq); >> >> if (cpu == smp_processor_id()) { >> - set_tsk_need_resched(curr, RESCHED_eager); >> - set_preempt_need_resched(); >> + set_tsk_need_resched(curr, rs); >> + if (rs == RESCHED_eager) >> + set_preempt_need_resched(); >> return; >> } >> >> - if (set_nr_and_not_polling(curr, RESCHED_eager)) >> - smp_send_reschedule(cpu); >> - else >> + if (set_nr_and_not_polling(curr, rs)) { >> + if (rs == RESCHED_eager) >> + smp_send_reschedule(cpu); > > I think you just broke things. > > Not all idle threads have POLLING support, in which case you need that > IPI to wake them up, even if it's LAZY. Yes, I was concerned about that too. But doesn't this check against the idle_sched_class in resched_curr() cover that? >> + if (IS_ENABLED(CONFIG_PREEMPT) || >> + (rq->curr->sched_class == &idle_sched_class)) { >> + rs = RESCHED_eager; >> + goto resched; >> + } else if (rs == RESCHED_eager) >> trace_sched_wake_idle_without_ipi(cpu); >> } > > > >> >> +/* >> + * resched_curr - mark rq's current task 'to be rescheduled' eagerly >> + * or lazily according to the current policy. >> + * >> + * Always schedule eagerly, if: >> + * >> + * - running under full preemption >> + * >> + * - idle: when not polling (or if we don't have TIF_POLLING_NRFLAG) >> + * force TIF_NEED_RESCHED to be set and send a resched IPI. >> + * (the polling case has already set TIF_NEED_RESCHED via >> + * set_nr_if_polling()). >> + * >> + * - in userspace: run to completion semantics are only for kernel tasks >> + * >> + * Otherwise (regardless of priority), run to completion. >> + */ >> +void resched_curr(struct rq *rq) >> +{ >> + resched_t rs = RESCHED_lazy; >> + int context; >> + >> + if (IS_ENABLED(CONFIG_PREEMPT) || >> + (rq->curr->sched_class == &idle_sched_class)) { >> + rs = RESCHED_eager; >> + goto resched; >> + } >> + >> + /* >> + * We might race with the target CPU while checking its ct_state: >> + * >> + * 1. The task might have just entered the kernel, but has not yet >> + * called user_exit(). We will see stale state (CONTEXT_USER) and >> + * send an unnecessary resched-IPI. >> + * >> + * 2. The user task is through with exit_to_user_mode_loop() but has >> + * not yet called user_enter(). >> + * >> + * We'll see the thread's state as CONTEXT_KERNEL and will try to >> + * schedule it lazily. There's obviously nothing that will handle >> + * this need-resched bit until the thread enters the kernel next. >> + * >> + * The scheduler will still do tick accounting, but a potentially >> + * higher priority task waited to be scheduled for a user tick, >> + * instead of execution time in the kernel. >> + */ >> + context = ct_state_cpu(cpu_of(rq)); >> + if ((context == CONTEXT_USER) || >> + (context == CONTEXT_GUEST)) { >> + >> + rs = RESCHED_eager; >> + goto resched; >> + } > > Like said, this simply cannot be. You must not rely on the remote CPU > being in some state or not. Also, it's racy, you could observe USER and > then it enters KERNEL. Or worse. We might observe KERNEL and it enters USER. I think we would be fine if we observe USER: it would be upgrade to RESCHED_eager and send an unnecessary IPI. But if we observe KERNEL and it enters USER, then we will have set the need-resched-lazy bit which the thread might not see (it might have left exit_to_user_mode_loop()) until the next entry to the kernel. But, yes I would like to avoid the ct_state as well. But need-resched-lazy only makes sense when the task on the runqueue is executing in the kernel... -- ankur
On Wed, Nov 08, 2023 at 02:26:37AM -0800, Ankur Arora wrote: > > Peter Zijlstra <peterz@infradead.org> writes: > > > On Tue, Nov 07, 2023 at 01:57:27PM -0800, Ankur Arora wrote: > > > >> --- a/kernel/sched/core.c > >> +++ b/kernel/sched/core.c > >> @@ -1027,13 +1027,13 @@ void wake_up_q(struct wake_q_head *head) > >> } > >> > >> /* > >> - * resched_curr - mark rq's current task 'to be rescheduled now'. > >> + * __resched_curr - mark rq's current task 'to be rescheduled'. > >> * > >> - * On UP this means the setting of the need_resched flag, on SMP it > >> - * might also involve a cross-CPU call to trigger the scheduler on > >> - * the target CPU. > >> + * On UP this means the setting of the need_resched flag, on SMP, for > >> + * eager resched it might also involve a cross-CPU call to trigger > >> + * the scheduler on the target CPU. > >> */ > >> -void resched_curr(struct rq *rq) > >> +void __resched_curr(struct rq *rq, resched_t rs) > >> { > >> struct task_struct *curr = rq->curr; > >> int cpu; > >> @@ -1046,17 +1046,77 @@ void resched_curr(struct rq *rq) > >> cpu = cpu_of(rq); > >> > >> if (cpu == smp_processor_id()) { > >> - set_tsk_need_resched(curr, RESCHED_eager); > >> - set_preempt_need_resched(); > >> + set_tsk_need_resched(curr, rs); > >> + if (rs == RESCHED_eager) > >> + set_preempt_need_resched(); > >> return; > >> } > >> > >> - if (set_nr_and_not_polling(curr, RESCHED_eager)) > >> - smp_send_reschedule(cpu); > >> - else > >> + if (set_nr_and_not_polling(curr, rs)) { > >> + if (rs == RESCHED_eager) > >> + smp_send_reschedule(cpu); > > > > I think you just broke things. > > > > Not all idle threads have POLLING support, in which case you need that > > IPI to wake them up, even if it's LAZY. > > Yes, I was concerned about that too. But doesn't this check against the > idle_sched_class in resched_curr() cover that? I that's what that was. Hmm, maybe. I mean, we have idle-injection too, those don't as FIFO, but as such, they can only get preempted from RT/DL, and those will already force preempt anyway. The way you've split and structured the code makes it very hard to follow. Something like: if (set_nr_and_not_polling(curr, rs) && (rs == RESCHED_force || is_idle_task(curr))) smp_send_reschedule(); is *far* clearer, no?
Ankur Arora <ankur.a.arora@oracle.com> writes: > Peter Zijlstra <peterz@infradead.org> writes: > >> On Tue, Nov 07, 2023 at 01:57:27PM -0800, Ankur Arora wrote: >> >>> + * We might race with the target CPU while checking its ct_state: >>> + * >>> + * 1. The task might have just entered the kernel, but has not yet >>> + * called user_exit(). We will see stale state (CONTEXT_USER) and >>> + * send an unnecessary resched-IPI. >>> + * >>> + * 2. The user task is through with exit_to_user_mode_loop() but has >>> + * not yet called user_enter(). >>> + * >>> + * We'll see the thread's state as CONTEXT_KERNEL and will try to >>> + * schedule it lazily. There's obviously nothing that will handle >>> + * this need-resched bit until the thread enters the kernel next. >>> + * >>> + * The scheduler will still do tick accounting, but a potentially >>> + * higher priority task waited to be scheduled for a user tick, >>> + * instead of execution time in the kernel. >>> + */ >>> + context = ct_state_cpu(cpu_of(rq)); >>> + if ((context == CONTEXT_USER) || >>> + (context == CONTEXT_GUEST)) { >>> + >>> + rs = RESCHED_eager; >>> + goto resched; >>> + } >> >> Like said, this simply cannot be. You must not rely on the remote CPU >> being in some state or not. Also, it's racy, you could observe USER and >> then it enters KERNEL. > > Or worse. We might observe KERNEL and it enters USER. > > I think we would be fine if we observe USER: it would be upgrade > to RESCHED_eager and send an unnecessary IPI. > > But if we observe KERNEL and it enters USER, then we will have > set the need-resched-lazy bit which the thread might not see > (it might have left exit_to_user_mode_loop()) until the next > entry to the kernel. > > But, yes I would like to avoid the ct_state as well. But > need-resched-lazy only makes sense when the task on the runqueue > is executing in the kernel... So, I discussed this with Thomas offlist, and he pointed out that I'm overengineering this. If we decide to wake up a remote rq lazily with (!sched_feat(TTWU_QUEUE)), and if the target is running in user space, then the resched would happen when the process enters kernel mode. That's somewhat similar to how in this preemption model we let a task run for upto one extra tick while in kernel mode. So I'll drop this and allow the same behaviour in userspace instead of solving it in unnecessarily complicated ways. -- ankur
Peter Zijlstra <peterz@infradead.org> writes: > On Wed, Nov 08, 2023 at 02:26:37AM -0800, Ankur Arora wrote: >> >> Peter Zijlstra <peterz@infradead.org> writes: >> >> > On Tue, Nov 07, 2023 at 01:57:27PM -0800, Ankur Arora wrote: >> > >> >> --- a/kernel/sched/core.c >> >> +++ b/kernel/sched/core.c >> >> @@ -1027,13 +1027,13 @@ void wake_up_q(struct wake_q_head *head) >> >> } >> >> >> >> /* >> >> - * resched_curr - mark rq's current task 'to be rescheduled now'. >> >> + * __resched_curr - mark rq's current task 'to be rescheduled'. >> >> * >> >> - * On UP this means the setting of the need_resched flag, on SMP it >> >> - * might also involve a cross-CPU call to trigger the scheduler on >> >> - * the target CPU. >> >> + * On UP this means the setting of the need_resched flag, on SMP, for >> >> + * eager resched it might also involve a cross-CPU call to trigger >> >> + * the scheduler on the target CPU. >> >> */ >> >> -void resched_curr(struct rq *rq) >> >> +void __resched_curr(struct rq *rq, resched_t rs) >> >> { >> >> struct task_struct *curr = rq->curr; >> >> int cpu; >> >> @@ -1046,17 +1046,77 @@ void resched_curr(struct rq *rq) >> >> cpu = cpu_of(rq); >> >> >> >> if (cpu == smp_processor_id()) { >> >> - set_tsk_need_resched(curr, RESCHED_eager); >> >> - set_preempt_need_resched(); >> >> + set_tsk_need_resched(curr, rs); >> >> + if (rs == RESCHED_eager) >> >> + set_preempt_need_resched(); >> >> return; >> >> } >> >> >> >> - if (set_nr_and_not_polling(curr, RESCHED_eager)) >> >> - smp_send_reschedule(cpu); >> >> - else >> >> + if (set_nr_and_not_polling(curr, rs)) { >> >> + if (rs == RESCHED_eager) >> >> + smp_send_reschedule(cpu); >> > >> > I think you just broke things. >> > >> > Not all idle threads have POLLING support, in which case you need that >> > IPI to wake them up, even if it's LAZY. >> >> Yes, I was concerned about that too. But doesn't this check against the >> idle_sched_class in resched_curr() cover that? > > I that's what that was. Hmm, maybe. > > I mean, we have idle-injection too, those don't as FIFO, but as such, > they can only get preempted from RT/DL, and those will already force > preempt anyway. Aah yes, of course those are FIFO. Thanks missed that. > The way you've split and structured the code makes it very hard to > follow. Something like: > > if (set_nr_and_not_polling(curr, rs) && > (rs == RESCHED_force || is_idle_task(curr))) > smp_send_reschedule(); > > is *far* clearer, no? Nods. I was trying to separate where we decide whether we do things eagerly or lazily. But this is way clearer. -- ankur
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 01df5ac2982c..f65bf3ce0e9d 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1027,13 +1027,13 @@ void wake_up_q(struct wake_q_head *head) } /* - * resched_curr - mark rq's current task 'to be rescheduled now'. + * __resched_curr - mark rq's current task 'to be rescheduled'. * - * On UP this means the setting of the need_resched flag, on SMP it - * might also involve a cross-CPU call to trigger the scheduler on - * the target CPU. + * On UP this means the setting of the need_resched flag, on SMP, for + * eager resched it might also involve a cross-CPU call to trigger + * the scheduler on the target CPU. */ -void resched_curr(struct rq *rq) +void __resched_curr(struct rq *rq, resched_t rs) { struct task_struct *curr = rq->curr; int cpu; @@ -1046,17 +1046,77 @@ void resched_curr(struct rq *rq) cpu = cpu_of(rq); if (cpu == smp_processor_id()) { - set_tsk_need_resched(curr, RESCHED_eager); - set_preempt_need_resched(); + set_tsk_need_resched(curr, rs); + if (rs == RESCHED_eager) + set_preempt_need_resched(); return; } - if (set_nr_and_not_polling(curr, RESCHED_eager)) - smp_send_reschedule(cpu); - else + if (set_nr_and_not_polling(curr, rs)) { + if (rs == RESCHED_eager) + smp_send_reschedule(cpu); + } else if (rs == RESCHED_eager) trace_sched_wake_idle_without_ipi(cpu); } +/* + * resched_curr - mark rq's current task 'to be rescheduled' eagerly + * or lazily according to the current policy. + * + * Always schedule eagerly, if: + * + * - running under full preemption + * + * - idle: when not polling (or if we don't have TIF_POLLING_NRFLAG) + * force TIF_NEED_RESCHED to be set and send a resched IPI. + * (the polling case has already set TIF_NEED_RESCHED via + * set_nr_if_polling()). + * + * - in userspace: run to completion semantics are only for kernel tasks + * + * Otherwise (regardless of priority), run to completion. + */ +void resched_curr(struct rq *rq) +{ + resched_t rs = RESCHED_lazy; + int context; + + if (IS_ENABLED(CONFIG_PREEMPT) || + (rq->curr->sched_class == &idle_sched_class)) { + rs = RESCHED_eager; + goto resched; + } + + /* + * We might race with the target CPU while checking its ct_state: + * + * 1. The task might have just entered the kernel, but has not yet + * called user_exit(). We will see stale state (CONTEXT_USER) and + * send an unnecessary resched-IPI. + * + * 2. The user task is through with exit_to_user_mode_loop() but has + * not yet called user_enter(). + * + * We'll see the thread's state as CONTEXT_KERNEL and will try to + * schedule it lazily. There's obviously nothing that will handle + * this need-resched bit until the thread enters the kernel next. + * + * The scheduler will still do tick accounting, but a potentially + * higher priority task waited to be scheduled for a user tick, + * instead of execution time in the kernel. + */ + context = ct_state_cpu(cpu_of(rq)); + if ((context == CONTEXT_USER) || + (context == CONTEXT_GUEST)) { + + rs = RESCHED_eager; + goto resched; + } + +resched: + __resched_curr(rq, rs); +} + void resched_cpu(int cpu) { struct rq *rq = cpu_rq(cpu);