Messages in this thread | | | Date | Sun, 17 Nov 2019 11:29:52 +0100 | From | Ingo Molnar <> | Subject | Re: [GIT PULL] scheduler fixes |
| |
* Valentin Schneider <valentin.schneider@arm.com> wrote:
> On 17/11/2019 09:45, Ingo Molnar wrote: > > I've picked v2 up instead. I suspect it's not really consequential as > > enums don't really get truncated by compilers, right? Is there any other > > negative runtime side effect possible from the imprecise enum/uint > > typing? > > > > AFAIUI the requirement for the enum type is that it has to be an int type that > covers all its values, so I could see some funky optimization (e.g. check the > returned value is < 512 but it's assumed the type for the enum is 8 bits so > this becomes always true). Then again we don't have any explicit check on > those returned values, plus they fit in 11 bits, so as you say it's > mostly likely inconsequential (and I didn't see any compile diff).
Yeah, so unless there's evidence of there being a nonzero chance of this being misbuilt I'd gravitate towards doing this via via sched/core, especially so late in the cycle.
> My "worry" wasn't really about this patch, it was more about the > following one - it didn't like the idea of merging an unneeded patch > (with a Fixes: tag on top of it).
Yeah, agreed - should be fixed now.
> >>> sched/topology, cpuset: Account for housekeeping CPUs to avoid empty cpumasks > >> > >> And this one is no longer needed, as Michal & I understood (IOW the fix in > >> rc6 is sufficient), see: > >> > >> c425c5cb-ba8a-e5f6-d91c-5479779cfb7a@arm.com > > > > Ok. > > > > I'm inclined to just reduce sched/urgent back to these three fixes: > > > > 6e1ff0773f49: sched/uclamp: Fix incorrect condition > > b90f7c9d2198: sched/pelt: Fix update of blocked PELT ordering > > ff51ff84d82a: sched/core: Avoid spurious lock dependencies > > > > and apply v2 of the uclamp_id type fix to sched/core. This would reduce > > the risks of a Sunday pull request ... > > > > This sounds good to me. Sorry for the hassle.
No hassle at all - thanks for catching these!
Thanks,
Ingo
| |