On Thu, Aug 01, 2019 at 01:27:03PM +0200, Geert Uytterhoeven wrote: > Hi Peter, > > On Thu, Aug 1, 2019 at 1:18 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > The SPI thingies request FIFO-99 by default, reduce this to FIFO-50. > > > > FIFO-99 is the very highest priority available to SCHED_FIFO and > > it not a suitable default; it would indicate the SPI work is the > > most important work on the machine. > > > > Cc: Benson Leung <bleung@xxxxxxxxxxxx> > > Cc: Enric Balletbo i Serra <enric.balletbo@xxxxxxxxxxxxx> > > Cc: Guenter Roeck <groeck@xxxxxxxxxxxx> > > Cc: Mark Brown <broonie@xxxxxxxxxx> > > Cc: linux-spi@xxxxxxxxxxxxxxx > > Cc: linux-kernel@xxxxxxxxxxxxxxx > > Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx> > > --- > > drivers/platform/chrome/cros_ec_spi.c | 2 +- > > drivers/spi/spi.c | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > --- a/drivers/platform/chrome/cros_ec_spi.c > > +++ b/drivers/platform/chrome/cros_ec_spi.c > > @@ -706,7 +706,7 @@ static int cros_ec_spi_devm_high_pri_all > > struct cros_ec_spi *ec_spi) > > { > > struct sched_param sched_priority = { > > - .sched_priority = MAX_RT_PRIO - 1, > > + .sched_priority = MAX_RT_PRIO / 2, > > include/linux/sched/prio.h says: > > * Priority of a process goes from 0..MAX_PRIO-1, valid RT > * priority is 0..MAX_RT_PRIO-1, and SCHED_NORMAL/SCHED_BATCH > * tasks are in the range MAX_RT_PRIO..MAX_PRIO-1. Priority > * values are inverted: lower p->prio value means higher priority. > > So the new 50 is actually a higher priority than the old 99? > > Given I'm far from an RT expert, I must be missing something? > Thanks! Ah; you found the confusion ;-) https://lkml.kernel.org/20190617122448.GA3436@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx But basically, user-space prio is [1-99], while in-kernel prio is [0-98]. The above is user prio (it basically uses the sched_setscheduler() syscall). So 50 really is lower than 99.