maria-discuss team mailing list archive

[Michael Widenius <monty@xxxxxxxxxxxx>]

Hi!

>>>>> "Panayot" == Panayot Belchev <panayot@xxxxxxxxxxx> writes:

Panayot> Hi,
Panayot> I just noticed that all our MariaDB 5.2 servers show the same:

Panayot> $ ps -eo ni,comm |grep mysql

Panayot>   9 mysqld_safe
Panayot>  19 mysql_isam_spac <defunct>
Panayot>  19 mysqld

I digged a bit deeper into this

Panayot> While servers with Oracle MySQL are at nice -n 0


pthread_setschedparam() uses sched_getscheduler() to set the priority.

It's called with pthread_setschedparam(thread, POLICY, &sp), where
POLICY == SCHED_OTHER 

>From 'man sched_setscheduler'

   Scheduling Policies
       The  scheduler  is  the  kernel  component  that decides which runnable
       process will be executed by the CPU next.  Each process has an  associ
       ated  scheduling  policy and a static scheduling priority, sched_prior
       ity; these are the settings that are modified by  sched_setscheduler().
       The  scheduler  makes it decisions based on knowledge of the scheduling
       policy and static priority of all processes on the system.

       For processes scheduled under one of  the  normal  scheduling  policies
       (SCHED_OTHER,  SCHED_IDLE,  SCHED_BATCH), sched_priority is not used in
       scheduling decisions (it must be specified as 0).

As you are calling this with sched_priority <> 0,
pthread_setschedparam() will return EINVAL which has the effect that
pth_min_priority and pth_max_priority are always 0, which casues
xt_p_set_low_priority() to misbehave.

This is at least the case on SuSE 11.4 and Linux 2.6.37.6-0.5.

Regards,
Monty