Received-SPF: pass (google.com: domain of linux-kernel+bounces-96488-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
References: <20240213055554.1802415-1-ankur.a.arora@oracle.com>
 <20240213055554.1802415-27-ankur.a.arora@oracle.com>
 <65e3cd87.050a0220.bc052.7a29@mx.google.com> <87frx514jz.fsf@oracle.com>
 <12a20651-5429-43df-88d7-9d01ff6212c6@joelfernandes.org>
 <63380f0a-329c-43df-8e6c-4818de5eb371@paulmck-laptop>
 <d956c2e9-492d-4559-b9f9-400f37f523bf@joelfernandes.org>
User-agent: mu4e 1.4.10; emacs 27.2
From: Ankur Arora <ankur.a.arora@oracle.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: paulmck@kernel.org, Ankur Arora <ankur.a.arora@oracle.com>,
        linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org,
        torvalds@linux-foundation.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,
        jpoimboe@kernel.org, mark.rutland@arm.com, jgross@suse.com,
        andrew.cooper3@citrix.com, 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,
        jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com,
        boris.ostrovsky@oracle.com, konrad.wilk@oracle.com
Subject: Re: [PATCH 26/30] sched: handle preempt=voluntary under PREEMPT_AUTO
In-reply-to: <d956c2e9-492d-4559-b9f9-400f37f523bf@joelfernandes.org>
Message-ID: <87edclqt6a.fsf@oracle.com>
Date: Thu, 07 Mar 2024 19:49:33 -0800
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?us-ascii?Q?VdgCijvH0sbdgxcrUML2mNeTPoqYWrgobJ126p9Hyow+A+uYuDAjyMpMA51j?=
 =?us-ascii?Q?GRV8M5Igog+lhG2Wx5alWcK+u47pBZ2awYSkMPMb+OL2BCtGiBs7sR7l6P8P?=
 =?us-ascii?Q?3hPhqVmqqPjNWSfOWynGXW5/RzRC9aMR+NO+yjNLWLZSGTOZ/8OMxvkoJNkH?=
 =?us-ascii?Q?+MMQp5Yb4Pu+lXbGov19mxPjh9GkmFd4sIKeFYTLHrH1iUqhEDwEnVAM2qhi?=
 =?us-ascii?Q?MFaCwyCnqrszbMMpf4h+w3VzfK06QqBhNPzNYtIk1h/rBPOj2m8EWPj9jQXU?=
 =?us-ascii?Q?sqNndmvHqRDlKy02isYXoc2QudMAYmfbQFtQ7fAx3MqGbCozj2fkD8wmDQLH?=
 =?us-ascii?Q?9T9qacWICZM8+ROvpxzbEh8PR3P4l3J4+PD9uiG6CzYqG87IPz5GJpQUmkhg?=
 =?us-ascii?Q?zCfpEhgqynzsSJzIcHapiI34srLuhE4qKfFrzbAYkdWg8C19yDjQ3g/HDZSi?=
 =?us-ascii?Q?ZZN6CrnR6prlDfuQoLNXPl8GCJHhTZiuK/J96M2lYhQlcdcrWZMXoSz/ddto?=
 =?us-ascii?Q?cWeyOjQxKUll8MJhhn4K8IfvxBJNGcL4xutG3EN7OVI+0cWnVKfpKdzCzG5o?=
 =?us-ascii?Q?iaFNuBRbUdn4ri2jwq5giGjaYcsjsy/zExuw8EJ+s9gyIoxdY5Yi5E76ecab?=
 =?us-ascii?Q?GEs7Mk/O6wH0z0y23NcbSBzmhImoPwtnhdaNJ2EBH0E6wrH5LKriDXxsuFZ/?=
 =?us-ascii?Q?ZAcMveuCZlw4EnvA/njvmX7RL5DPhKQCA1Gm5MdOTukcHNtXBFQySHbGCWAV?=
 =?us-ascii?Q?wm+Qvc8nENGe1QDZTh72JyFVlqpx/UH9r572+r4Lrq9mOxrtvYlu5LDRx8Cm?=
 =?us-ascii?Q?SnKF1Cv2DBGPO28PKlWAhi8XrfbrFJkH4zCJki6yKB9A1uTDOwGTCy6zXdXq?=
 =?us-ascii?Q?7HG153/30RkiUMvwmtx89ltnLmeOJ7mf+Dozefy4kriWzCb9TfS4WDErqIL3?=
 =?us-ascii?Q?tKrkt0/QuBUL+HxBSsTlzvcwXz5MsJzN9ax3JWkPPp01NP0EYAHn8eSNYPkz?=
 =?us-ascii?Q?hz7/DLU9B4V2dhXG5CAuH0Ah7/rRjlC79ReWfB/Pb+R4kQpE1nTkhyjqbR+G?=
 =?us-ascii?Q?NBIXe/xbS+4LvHzxOkbOVpBFgqdyEJKdRTKfp9mpRC22RpIPvfhjYSM7Mg8c?=
 =?us-ascii?Q?0rbpbK+fMO6cMu3jOJ9CoYRg76inx1uUHGsVZSYkkz5SWQlqozCMKPW58Flo?=
 =?us-ascii?Q?U1wmVCfe/A5NRdSw4SD4kpcPRS/fp7nOGOu0hTpchJqMOJEH/3iKR83mT99U?=
 =?us-ascii?Q?5iVUurCdExAgeccjIetwDmZG6zkNsCmuGgm1olBgeMHakb2oolx3JhzZAx8u?=
 =?us-ascii?Q?3oFK2qM5tA8/3GvliSEBDH0EK9xFRWN/VgbIxCbtqGd+u+aGyxwl3DkUBWfv?=
 =?us-ascii?Q?k12m+uenWL0brJHL/QHdzRlpgCRt+5en9KWpj9GT4y3O9r5KTMO4LHfQFUh0?=
 =?us-ascii?Q?PS2mXrjLdQaSHkib5I2eSynyaB+YeQMwc7h+BVaiq+yAIdiECQDbukCeGRa3?=
 =?us-ascii?Q?+BkMxCgubRCfhZgFq+H/iOLBh6XM/DVw+XzeFpfqFoZsxZUjpXpC+Yc+QYKn?=
 =?us-ascii?Q?EqNlqrK3wC9kHyJL+HBKA4rTszJLn7IgdFfyLZ9pqItN5kjlea6NJ09DZjQG?=
 =?us-ascii?Q?bw=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	j817jy4b9s9LKIUeRErQwQaXNTpxhKYtk1kkU8sVEPLxwb/kLiBVzn7aS2ttsIYFtjuoC7XnVSn6XXFkq62IBIwMH+Trok0y1qCn5l2rix0x7fWLB/arxA2Ei3dDf6WWMxmK7/VpwuRZXXJqwmYYoyzrVmBGFe+GS0XnOnVHrPyYVZCcD8cY58GgxARUZEuFo103LFsxIkXT4EqLhpW7A7Ee5oErlqfi+GzRMRI3jUAjoYUMCRwsp/UCoEKP5DlSoji+hH3KVnl9u7OjSRLi+aISBB2gyzJBdtqkVnVABKsUFuFonKoOmHOhxSqH72Vv7q7JcZrNg2XKJ/0RWA9+Ik3Ocvd+nLNK/1ROhfuSmNUcpWDdZE8uwYPVGB6Bf3/YFagbnQwqAyRSbb12nIbGoihncARf1+OIvWyDA5MHJvG/e7McQYO1u6Gp1CJtYFms2Emp9tk0eZLkQjIHHBcC39qBU5CvKkZ4TnV+boAucWB+bzFTIWZJeyumWM10J78iVuV/gnzYImxGUGALcpP8W0sWXzAB2st6cUbWl1g6SVa+97ozfT2O9VxmJF6rN3kMVMRPFitm1dEYQzZ5FrotX4XQZ9k/ySeWgor2GIwhGtg=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a933b4c3-82e5-431e-0420-08dc3f22b24e
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5421.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2024 03:49:03.5034
 (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: yDA8oQT9sE/8vIzS9MdCOSMBPbEjRMVMFzmbonITJWXCEh+2ZCGfDh0LrT19Kgr8128LJR7Kk7x2E7WjQpdLqc09nA5vf/G6nPghKOEx8f0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR10MB6237
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-08_02,2024-03-06_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0
 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0 phishscore=0
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2311290000 definitions=main-2403080028
X-Proofpoint-ORIG-GUID: nURfnqNHT8kLFd1kloRTZVzm7CuN5bqs
X-Proofpoint-GUID: nURfnqNHT8kLFd1kloRTZVzm7CuN5bqs


Joel Fernandes <joel@joelfernandes.org> writes:

> On 3/7/2024 2:01 PM, Paul E. McKenney wrote:
>> On Wed, Mar 06, 2024 at 03:42:10PM -0500, Joel Fernandes wrote:
>>> Hi Ankur,
>>>
>>> On 3/5/2024 3:11 AM, Ankur Arora wrote:
>>>>
>>>> Joel Fernandes <joel@joelfernandes.org> writes:
>>>>
>>> [..]
>>>>> IMO, just kill 'voluntary' if PREEMPT_AUTO is enabled. There is no
>>>>> 'voluntary' business because
>>>>> 1. The behavior vs =none is to allow higher scheduling class to preempt, it
>>>>> is not about the old voluntary.
>>>>
>>>> What do you think about folding the higher scheduling class preemption logic
>>>> into preempt=none? As Juri pointed out, prioritization of at least the leftmost
>>>> deadline task needs to be done for correctness.
>>>>
>>>> (That'll get rid of the current preempt=voluntary model, at least until
>>>> there's a separate use for it.)
>>>
>>> Yes I am all in support for that. Its less confusing for the user as well, and
>>> scheduling higher priority class at the next tick for preempt=none sounds good
>>> to me. That is still an improvement for folks using SCHED_DEADLINE for whatever
>>> reason, with a vanilla CONFIG_PREEMPT_NONE=y kernel. :-P. If we want a new mode
>>> that is more aggressive, it could be added in the future.
>>
>> This would be something that happens only after removing cond_resched()
>> might_sleep() functionality from might_sleep(), correct?
>
> Firstly, Maybe I misunderstood Ankur completely. Re-reading his comments above,
> he seems to be suggesting preempting instantly for higher scheduling CLASSES
> even for preempt=none mode, without having to wait till the next
> scheduling-clock interrupt.

Yes, that's what I was suggesting.

> Not sure if that makes sense to me, I was asking not
> to treat "higher class" any differently than "higher priority" for preempt=none.

Ah. Understood.

> And if SCHED_DEADLINE has a problem with that, then it already happens so with
> CONFIG_PREEMPT_NONE=y kernels, so no need special treatment for higher class any
> more than the treatment given to higher priority within same class. Ankur/Juri?

No. I think that behaviour might be worse for PREEMPT_AUTO.

PREEMPT_NONE=y (or PREEMPT_VOLUNTARY=y for that matter) don't
quite have a policy around when preemption happens. Preemption
might happen quickly, might happen slowly based on when the next
preemption point is found.

The PREEMPT_AUTO, preempt=none policy in this series will always
cause preemption to be at user exit or the next tick. Seems like
it would be worse for higher scheduling classes more often.

But, I wonder what Juri thinks about this.

--
ankur