[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <af031e33-74db-40ba-abdd-ef1bf32e4caf@redhat.com>
Date: Wed, 5 Jun 2024 16:07:37 +0200
From: Daniel Bristot de Oliveira <bristot@...hat.com>
To: Qais Yousef <qyousef@...alina.io>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Ingo Molnar <mingo@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>, Steven Rostedt <rostedt@...dmis.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Alexander Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>,
Metin Kaya <metin.kaya@....com>, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
linux-mm@...ck.org, Phil Auld <pauld@...hat.com>
Subject: Re: [PATCH v5 1/2] sched/rt: Clean up usage of rt_task()
On 6/5/24 15:24, Qais Yousef wrote:
>>> But rt is a shortened version of realtime, and so it is making *it less*
>>> clear that we also have DL here.
>> Can SCHED_DL be considered a real-time scheduling class as in opposite
>> to SCHED_BATCH for instance? Due to its requirements it fits for a real
>> time scheduling class, right?
>> And RT (as in real time) already includes SCHED_RR and SCHED_FIFO.
> Yeah I think the usage of realtime to cover both makes sense. I followed your
> precedence with task_is_realtime().
>
> Anyway. If people really find this confusing, what would make sense is to split
> them and ask users to call rt_task() and dl_task() explicitly without this
> wrapper. I personally like it better with the wrapper. But happy to follow the
> crowd.
For me, doing dl_ things it is better to keep them separate, so I can
easily search for dl_ specific checks.
rt_or_dl_task(p);
would also make it clear that we have both.
-- Daniel
Powered by blists - more mailing lists