[ Missed this email until now. ] Thomas Gleixner writes: >On Fri, Jan 12 2024 at 07:27, Dave Chinner wrote: > >Cc: Ankur > > > On Thu, Jan 11, 2024 at 08:52:22PM +0800, Jian Wen wrote: > >> On Thu, Jan 11, 2024 at 5:38 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > >> > IOWs, this is no longer considered an acceptible solution by core > >> > kernel maintainers. > >> Understood. I will only build a hotfix for our production kernel then. > > > > Yeah, that may be your best short term fix. We'll need to clarify > > what the current policy is on adding cond_resched points before we > > go any further in this direction. > > Well, right now until the scheduler situation is sorted there is no > other solution than to add the cond_resched() muck. > > > Thomas, any update on what is happening with cond_resched() - is > > there an ETA on it going away/being unnecessary? > > Ankur is working on that... Yeah, running through a final round of tests before sending out the series. Dave, on the status of cond_resched(): the work on this adds a new scheduling model (as Thomas implemented in his PoC) undwer which cond_resched() would basically be a stub. However, given that other preemption models continue to use cond_resched(), we would need to live with cond_resched() for a while -- at least while this model works well enough under a wide enough variety of loads. Thanks Ankur
