Utilisation élevée du processeur avec CFS?


25

J'ai posé une question précédente pour essayer d'isoler la source d'une augmentation de l'utilisation du processeur lors du déplacement d'une application de RHEL 5 vers RHEL 6. L'analyse que j'ai faite pour cela semble indiquer qu'elle est causée par le CFS dans le noyau. J'ai écrit une application de test pour essayer de vérifier si c'était le cas (application de test d'origine supprimée pour tenir dans la limite de taille, mais toujours disponible dans git repo .

Je l'ai compilé avec la commande suivante sur RHEL 5:

cc test_select_work.c -O2 -DSLEEP_TYPE=0 -Wall -Wextra -lm -lpthread -o test_select_work

J'ai ensuite joué avec les paramètres jusqu'à ce que le temps d'exécution par itération soit d'environ 1 ms sur un Dell Precision m6500.

J'ai obtenu le résultat suivant sur RHEL 5:

./test_select_work 1000 10000 300 4
time_per_iteration: min: 911.5 us avg: 913.7 us max: 917.1 us stddev: 2.4 us
./test_select_work 1000 10000 300 8
time_per_iteration: min: 1802.6 us avg: 1803.9 us max: 1809.1 us stddev: 2.1 us
./test_select_work 1000 10000 300 40
time_per_iteration: min: 7580.4 us avg: 8567.3 us max: 9022.0 us stddev: 299.6 us

Et ce qui suit sur RHEL 6:

./test_select_work 1000 10000 300 4
time_per_iteration: min: 914.6 us avg: 975.7 us max: 1034.5 us stddev: 50.0 us
./test_select_work 1000 10000 300 8
time_per_iteration: min: 1683.9 us avg: 1771.8 us max: 1810.8 us stddev: 43.4 us
./test_select_work 1000 10000 300 40
time_per_iteration: min: 7997.1 us avg: 8709.1 us max: 9061.8 us stddev: 310.0 us

Sur les deux versions, ces résultats correspondaient à ce que j'attendais, le temps moyen par itération étant relativement linéaire. J'ai ensuite recompilé avec -DSLEEP_TYPE=1et obtenu les résultats suivants sur RHEL 5:

./test_select_work 1000 10000 300 4
time_per_iteration: min: 1803.3 us avg: 1902.8 us max: 2001.5 us stddev: 113.8 us
./test_select_work 1000 10000 300 8
time_per_iteration: min: 1997.1 us avg: 2002.0 us max: 2010.8 us stddev: 5.0 us
./test_select_work 1000 10000 300 40
time_per_iteration: min: 6958.4 us avg: 8397.9 us max: 9423.7 us stddev: 619.7 us

Et les résultats suivants sur RHEL 6:

./test_select_work 1000 10000 300 4
time_per_iteration: min: 2107.1 us avg: 2143.1 us max: 2177.7 us stddev: 30.3 us
./test_select_work 1000 10000 300 8
time_per_iteration: min: 2903.3 us avg: 2903.8 us max: 2904.3 us stddev: 0.3 us
./test_select_work 1000 10000 300 40
time_per_iteration: min: 8877.7.1 us avg: 9016.3 us max: 9112.6 us stddev: 62.9 us

Sur RHEL 5, les résultats étaient à peu près ce à quoi je m'attendais (4 threads prenant deux fois plus de temps à cause du sommeil de 1 ms mais les 8 threads prenant le même temps car chaque thread est maintenant en sommeil pendant environ la moitié du temps, et encore assez augmentation linéaire).

Cependant, avec RHEL 6, le temps pris avec 4 fils a augmenté d'environ 15% de plus que le doublement attendu et le boîtier à 8 fils a augmenté d'environ 45% de plus que la légère augmentation attendue. L'augmentation dans le cas de 4 threads semble être que RHEL 6 est en train de dormir pendant une poignée de microsecondes de plus de 1 ms tandis que RHEL 5 ne dort qu'environ 900 nous, mais cela n'explique pas l'augmentation étonnamment importante des 8 et 40 cas de fil.

J'ai vu des types de comportement similaires avec toutes les 3 valeurs -DSLEEP_TYPE. J'ai également essayé de jouer avec les paramètres du planificateur dans sysctl, mais rien ne semblait avoir un impact significatif sur les résultats. Avez-vous des idées sur la façon de diagnostiquer davantage ce problème?

MISE À JOUR: 2012-05-07

J'ai ajouté des mesures de l'utilisation du processeur utilisateur et système à partir de / proc / stat // tâches // stat en sortie du test pour essayer d'obtenir un autre point d'observation. J'ai également trouvé un problème avec la façon dont la moyenne et l'écart-type étaient mis à jour qui a été introduit lorsque j'ai ajouté la boucle d'itération externe, donc j'ajouterai les nouveaux tracés qui ont les mesures corrigées de la moyenne et de l'écart-type. J'ai inclus le programme mis à jour. J'ai également fait un dépôt git pour suivre le code et il est disponible ici.

#include <limits.h>
#include <math.h>
#include <poll.h>
#include <pthread.h>
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
#include <sys/select.h>
#include <sys/syscall.h>
#include <sys/time.h>


// Apparently GLIBC doesn't provide a wrapper for this function so provide it here
#ifndef HAS_GETTID
pid_t gettid(void)
{
  return syscall(SYS_gettid);
}
#endif


// The different type of sleep that are supported
enum sleep_type {
  SLEEP_TYPE_NONE,
  SLEEP_TYPE_SELECT,
  SLEEP_TYPE_POLL,
  SLEEP_TYPE_USLEEP,
  SLEEP_TYPE_YIELD,
  SLEEP_TYPE_PTHREAD_COND,
  SLEEP_TYPE_NANOSLEEP,
};

// Information returned by the processing thread
struct thread_res {
  long long clock;
  long long user;
  long long sys;
};

// Function type for doing work with a sleep
typedef struct thread_res *(*work_func)(const int pid, const int sleep_time, const int num_iterations, const int work_size);

// Information passed to the thread
struct thread_info {
  pid_t pid;
  int sleep_time;
  int num_iterations;
  int work_size;
  work_func func;
};


inline void get_thread_times(pid_t pid, pid_t tid, unsigned long long *utime, unsigned long long *stime)
{
  char filename[FILENAME_MAX];
  FILE *f;

  sprintf(filename, "/proc/%d/task/%d/stat", pid, tid);
  f = fopen(filename, "r");
  if (f == NULL) {
    *utime = 0;
    *stime = 0;
    return;
  }

  fscanf(f, "%*d %*s %*c %*d %*d %*d %*d %*d %*u %*u %*u %*u %*u %Lu %Lu", utime, stime);

  fclose(f);
}

// In order to make SLEEP_TYPE a run-time parameter function pointers are used.
// The function pointer could have been to the sleep function being used, but
// then that would mean an extra function call inside of the "work loop" and I
// wanted to keep the measurements as tight as possible and the extra work being
// done to be as small/controlled as possible so instead the work is declared as
// a seriees of macros that are called in all of the sleep functions. The code
// is a bit uglier this way, but I believe it results in a more accurate test.

// Fill in a buffer with random numbers (taken from latt.c by Jens Axboe <jens.axboe@oracle.com>)
#define DECLARE_FUNC(NAME) struct thread_res *do_work_##NAME(const int pid, const int sleep_time, const int num_iterations, const int work_size)

#define DECLARE_WORK() \
  int *buf; \
  int pseed; \
  int inum, bnum; \
  pid_t tid; \
  struct timeval clock_before, clock_after; \
  unsigned long long user_before, user_after; \
  unsigned long long sys_before, sys_after; \
  struct thread_res *diff; \
  tid = gettid(); \
  buf = malloc(work_size * sizeof(*buf)); \
  diff = malloc(sizeof(*diff)); \
  get_thread_times(pid, tid, &user_before, &sys_before); \
  gettimeofday(&clock_before, NULL)

#define DO_WORK(SLEEP_FUNC) \
  for (inum=0; inum<num_iterations; ++inum) { \
    SLEEP_FUNC \
     \
    pseed = 1; \
    for (bnum=0; bnum<work_size; ++bnum) { \
      pseed = pseed * 1103515245 + 12345; \
      buf[bnum] = (pseed / 65536) % 32768; \
    } \
  } \

#define FINISH_WORK() \
  gettimeofday(&clock_after, NULL); \
  get_thread_times(pid, tid, &user_after, &sys_after); \
  diff->clock = 1000000LL * (clock_after.tv_sec - clock_before.tv_sec); \
  diff->clock += clock_after.tv_usec - clock_before.tv_usec; \
  diff->user = user_after - user_before; \
  diff->sys = sys_after - sys_before; \
  free(buf); \
  return diff

DECLARE_FUNC(nosleep)

{
  DECLARE_WORK();

  // Let the compiler know that sleep_time isn't used in this function
  (void)sleep_time;

  DO_WORK();

  FINISH_WORK();
}

DECLARE_FUNC(select)
{
  struct timeval ts;
  DECLARE_WORK();

  DO_WORK(
    ts.tv_sec = 0;
    ts.tv_usec = sleep_time;
    select(0, 0, 0, 0, &ts);
    );

  FINISH_WORK();
}

DECLARE_FUNC(poll)
{
  struct pollfd pfd;
  const int sleep_time_ms = sleep_time / 1000;
  DECLARE_WORK();

  pfd.fd = 0;
  pfd.events = 0;

  DO_WORK(
    poll(&pfd, 1, sleep_time_ms);
    );

  FINISH_WORK();
}

DECLARE_FUNC(usleep)
{
  DECLARE_WORK();

  DO_WORK(
    usleep(sleep_time);
    );

  FINISH_WORK();
}

DECLARE_FUNC(yield)
{
  DECLARE_WORK();

  // Let the compiler know that sleep_time isn't used in this function
  (void)sleep_time;

  DO_WORK(
    sched_yield();
    );

  FINISH_WORK();
}

DECLARE_FUNC(pthread_cond)
{
  pthread_cond_t cond  = PTHREAD_COND_INITIALIZER;
  pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
  struct timespec ts;
  const int sleep_time_ns = sleep_time * 1000;
  DECLARE_WORK();

  pthread_mutex_lock(&mutex);

  DO_WORK(
    clock_gettime(CLOCK_REALTIME, &ts);
    ts.tv_nsec += sleep_time_ns;
    if (ts.tv_nsec >= 1000000000) {
      ts.tv_sec += 1;
      ts.tv_nsec -= 1000000000;
    }
    pthread_cond_timedwait(&cond, &mutex, &ts);
    );

  pthread_mutex_unlock(&mutex);

  pthread_cond_destroy(&cond);
  pthread_mutex_destroy(&mutex);

  FINISH_WORK();
}

DECLARE_FUNC(nanosleep)
{
  struct timespec req, rem;
  const int sleep_time_ns = sleep_time * 1000;
  DECLARE_WORK();

  DO_WORK(
    req.tv_sec = 0;
    req.tv_nsec = sleep_time_ns;
    nanosleep(&req, &rem);
    );

  FINISH_WORK();
}

void *do_test(void *arg)
{
  const struct thread_info *tinfo = (struct thread_info *)arg;

  // Call the function to do the work
  return (*tinfo->func)(tinfo->pid, tinfo->sleep_time, tinfo->num_iterations, tinfo->work_size);
}

struct thread_res_stats {
  double min;
  double max;
  double avg;
  double stddev;
  double prev_avg;
};

#ifdef LLONG_MAX
  #define THREAD_RES_STATS_INITIALIZER {LLONG_MAX, LLONG_MIN, 0, 0, 0}
#else
  #define THREAD_RES_STATS_INITIALIZER {LONG_MAX, LONG_MIN, 0, 0, 0}
#endif

void update_stats(struct thread_res_stats *stats, long long value, int num_samples, int num_iterations, double scale_to_usecs)
{
  // Calculate the average time per iteration
  double value_per_iteration = value * scale_to_usecs / num_iterations;

  // Update the max and min
  if (value_per_iteration < stats->min)
    stats->min = value_per_iteration;
  if (value_per_iteration > stats->max)
    stats->max = value_per_iteration;
  // Update the average
  stats->avg += (value_per_iteration - stats->avg) / (double)(num_samples);
  // Update the standard deviation
  stats->stddev += (value_per_iteration - stats->prev_avg) * (value_per_iteration - stats->avg);
  // And record the current average for use in the next update
  stats->prev_avg= stats->avg;
}

void print_stats(const char *name, const struct thread_res_stats *stats)
{
  printf("%s: min: %.1f us avg: %.1f us max: %.1f us stddev: %.1f us\n",
      name,
      stats->min,
      stats->avg,
      stats->max,
      stats->stddev);
}

int main(int argc, char **argv)
{
  if (argc <= 6) {
    printf("Usage: %s <sleep_time> <outer_iterations> <inner_iterations> <work_size> <num_threads> <sleep_type>\n", argv[0]);
    printf("  outer_iterations: Number of iterations for each thread (used to calculate statistics)\n");
    printf("  inner_iterations: Number of work/sleep cycles performed in each thread (used to improve consistency/observability))\n");
    printf("  work_size: Number of array elements (in kb) that are filled with psuedo-random numbers\n");
    printf("  num_threads: Number of threads to spawn and perform work/sleep cycles in\n");
    printf("  sleep_type: 0=none 1=select 2=poll 3=usleep 4=yield 5=pthread_cond 6=nanosleep\n");
    return -1;
  }

  struct thread_info tinfo;
  int outer_iterations;
  int sleep_type;
  int s, inum, tnum, num_samples, num_threads;
  pthread_attr_t attr;
  pthread_t *threads;
  struct thread_res *res;
  struct thread_res **times;
  // Track the stats for each of the measurements
  struct thread_res_stats stats_clock = THREAD_RES_STATS_INITIALIZER;
  struct thread_res_stats stats_user = THREAD_RES_STATS_INITIALIZER;
  struct thread_res_stats stats_sys = THREAD_RES_STATS_INITIALIZER;
  // Calculate the conversion factor from clock_t to seconds
  const long clocks_per_sec = sysconf(_SC_CLK_TCK);
  const double clocks_to_usec = 1000000 / (double)clocks_per_sec;

  // Get the parameters
  tinfo.pid = getpid();
  tinfo.sleep_time = atoi(argv[1]);
  outer_iterations = atoi(argv[2]);
  tinfo.num_iterations = atoi(argv[3]);
  tinfo.work_size = atoi(argv[4]) * 1024;
  num_threads = atoi(argv[5]);
  sleep_type = atoi(argv[6]);
  switch (sleep_type) {
    case SLEEP_TYPE_NONE:   tinfo.func = &do_work_nosleep; break;
    case SLEEP_TYPE_SELECT: tinfo.func = &do_work_select;  break;
    case SLEEP_TYPE_POLL:   tinfo.func = &do_work_poll;    break;
    case SLEEP_TYPE_USLEEP: tinfo.func = &do_work_usleep;  break;
    case SLEEP_TYPE_YIELD:  tinfo.func = &do_work_yield;   break;
    case SLEEP_TYPE_PTHREAD_COND:  tinfo.func = &do_work_pthread_cond;   break;
    case SLEEP_TYPE_NANOSLEEP:  tinfo.func = &do_work_nanosleep;   break;
    default:
      printf("Invalid sleep type: %d\n", sleep_type);
      return -7;
  }

  // Initialize the thread creation attributes
  s = pthread_attr_init(&attr);
  if (s != 0) {
    printf("Error initializing thread attributes\n");
    return -2;
  }

  // Allocate the memory to track the threads
  threads = calloc(num_threads, sizeof(*threads));
  times = calloc(num_threads, sizeof(*times));
  if (threads == NULL) {
    printf("Error allocating memory to track threads\n");
    return -3;
  }

  // Initialize the number of samples
  num_samples = 0;
  // Perform the requested number of outer iterations
  for (inum=0; inum<outer_iterations; ++inum) {
    // Start all of the threads
    for (tnum=0; tnum<num_threads; ++tnum) {
      s = pthread_create(&threads[tnum], &attr, &do_test, &tinfo);

      if (s != 0) {
        printf("Error starting thread\n");
        return -4;
      }
    }

    // Wait for all the threads to finish
    for (tnum=0; tnum<num_threads; ++tnum) {
      s = pthread_join(threads[tnum], (void **)(&res));
      if (s != 0) {
        printf("Error waiting for thread\n");
        return -6;
      }

      // Save the result for processing when they're all done
      times[tnum] = res;
    }

    // For each of the threads
    for (tnum=0; tnum<num_threads; ++tnum) {
      // Increment the number of samples in the statistics
      ++num_samples;
      // Update the statistics with this measurement
      update_stats(&stats_clock, times[tnum]->clock, num_samples, tinfo.num_iterations, 1);
      update_stats(&stats_user, times[tnum]->user, num_samples, tinfo.num_iterations, clocks_to_usec);
      update_stats(&stats_sys, times[tnum]->sys, num_samples, tinfo.num_iterations, clocks_to_usec);
      // And clean it up
      free(times[tnum]);
    }
  }

  // Clean up the thread creation attributes
  s = pthread_attr_destroy(&attr);
  if (s != 0) {
    printf("Error cleaning up thread attributes\n");
    return -5;
  }

  // Finish the calculation of the standard deviation
  stats_clock.stddev = sqrtf(stats_clock.stddev / (num_samples - 1));
  stats_user.stddev = sqrtf(stats_user.stddev / (num_samples - 1));
  stats_sys.stddev = sqrtf(stats_sys.stddev / (num_samples - 1));

  // Print out the statistics of the times
  print_stats("gettimeofday_per_iteration", &stats_clock);
  print_stats("utime_per_iteration", &stats_user);
  print_stats("stime_per_iteration", &stats_sys);

  // Clean up the allocated threads and times
  free(threads);
  free(times);

  return 0;
}

J'ai relancé les tests sur un Dell Vostro 200 (CPU dual core) avec plusieurs versions de système d'exploitation différentes. Je me rends compte que plusieurs de ceux-ci auront des correctifs différents appliqués et ne seront pas du "code de noyau pur", mais c'était le moyen le plus simple pour exécuter les tests sur différentes versions du noyau et obtenir des comparaisons. J'ai généré des tracés avec gnuplot et j'ai inclus la version du bugzilla sur ce problème .

Tous ces tests ont été exécutés avec la commande suivante avec le script suivant et cette commande ./run_test 1000 10 1000 250 8 6 <os_name>.

#!/bin/bash

if [ $# -ne 7 ]; then
  echo "Usage: `basename $0` <sleep_time> <outer_iterations> <inner_iterations> <work_size> <max_num_threads> <max_sleep_type> <test_name>"
  echo "  max_num_threads: The highest value used for num_threads in the results"
  echo "  max_sleep_type: The highest value used for sleep_type in the results"
  echo "  test_name: The name of the directory where the results will be stored"
  exit -1
fi

sleep_time=$1
outer_iterations=$2
inner_iterations=$3
work_size=$4
max_num_threads=$5
max_sleep_type=$6
test_name=$7

# Make sure this results directory doesn't already exist
if [ -e $test_name ]; then
  echo "$test_name already exists";
  exit -1;
fi
# Create the directory to put the results in
mkdir $test_name
# Run through the requested number of SLEEP_TYPE values
for i in $(seq 0 $max_sleep_type)
do
  # Run through the requested number of threads
  for j in $(seq 1 $max_num_threads)
  do
    # Print which settings are about to be run
    echo "sleep_type: $i num_threads: $j"
    # Run the test and save it to the results file
    ./test_sleep $sleep_time $outer_iterations $inner_iterations $work_size $j $i >> "$test_name/results_$i.txt"
  done
done

Voici le résumé de ce que j'ai observé. Je vais les comparer par paires cette fois car je pense que c'est un peu plus instructif de cette façon.

CentOS 5.6 contre CentOS 6.2

Le temps d'horloge murale (gettimeofday) par itération sur CentOS 5.6 est plus varié que 6.2, mais cela a du sens car le CFS devrait faire un meilleur travail en donnant aux processus un temps CPU égal résultant en des résultats plus cohérents. Il est également assez clair que CentOS 6.2 est plus précis et cohérent dans la durée pendant laquelle il dort avec les différents mécanismes de sommeil. gettimeofday CentOS 5.6 gettimeofday CentOS 6.2

La "pénalité" est clairement apparente sur 6.2 avec un faible nombre de threads (visible sur gettimeofday et les graphiques de temps utilisateur) mais elle semble être réduite avec un nombre de threads plus élevé (la différence de temps utilisateur peut simplement être une chose comptable puisque le les mesures du temps utilisateur sont donc bien sûr).

utime CentOS 5.6 utime CentOS 6.2

Le graphique du temps système montre que les mécanismes de sommeil en 6.2 consomment plus de système qu'en 5.6, ce qui correspond aux résultats précédents du test simple de 50 processus appelant simplement select consommant une quantité non négligeable de CPU sur 6.2 mais pas 5.6 .

stime CentOS 5.6 stime CentOS 6.2

Quelque chose que je crois qui mérite d'être noté est que l'utilisation de sched_yield () n'induit pas la même pénalité que celle vue par les méthodes de sommeil. Ma conclusion est que ce n'est pas le planificateur lui-même qui est à l'origine du problème, mais l'interaction des méthodes de sommeil avec le planificateur qui est le problème.

Ubuntu 7.10 contre Ubuntu 8.04-4

La différence dans la version du noyau entre ces deux est plus petite que celle de CentOS 5.6 et 6.2, mais elles couvrent toujours la période de temps où CFS a été introduit. Le premier résultat intéressant est que select et poll semblent être les seuls mécanismes de sommeil qui ont la "pénalité" sur 8.04 et cette pénalité continue à un nombre de threads plus élevé que ce qui a été vu avec CentOS 6.2.

gettimeofday Ubuntu 7.10 gettimeofday Ubuntu 8.04-4

Le temps utilisateur pour sélectionner et interroger et Ubuntu 7.10 est déraisonnablement bas, donc cela semble être une sorte de problème de comptabilité qui existait à l'époque, mais je crois que cela n'est pas pertinent pour le problème / discussion actuel.

utime Ubuntu 7.10 utime Ubuntu 8.04-4

L'heure du système semble être plus élevée avec Ubuntu 8.04 qu'avec Ubuntu 7.10 mais cette différence est beaucoup moins distincte que ce qui a été vu avec CentOS 5.6 vs 6.2.

stime Ubuntu 7.10 stime Ubuntu 8.04-4

Remarques sur Ubuntu 11.10 et Ubuntu 12.04

La première chose à noter ici est que les tracés pour Ubuntu 12.04 étaient comparables à ceux de 11.10, donc ils ne montrent pas pour empêcher une redondance inutile.

Dans l'ensemble, les graphiques pour Ubuntu 11.10 montrent le même type de tendance qui a été observée avec CentOS 6.2 (ce qui indique qu'il s'agit d'un problème de noyau en général et pas seulement d'un problème RHEL). La seule exception est que le temps système semble être un peu plus élevé avec Ubuntu 11.10 qu'avec CentOS 6.2, mais encore une fois, la résolution de cette mesure est très bien sûr, donc je pense que toute conclusion autre que "il semble être un peu plus élevé "serait de marcher sur de la glace mince.

Ubuntu 11.10 vs Ubuntu 11.10 avec BFS

Un PPA qui utilise BFS avec le noyau Ubuntu peut être trouvé à https://launchpad.net/~chogydan/+archive/ppa et cela a été installé pour générer cette comparaison. Je ne pouvais pas trouver un moyen facile d'exécuter CentOS 6.2 avec BFS, j'ai donc exécuté cette comparaison et puisque les résultats d'Ubuntu 11.10 se comparent si bien avec CentOS 6.2, je pense que c'est une comparaison juste et significative.

gettimeofday Ubuntu 11.10 gettimeofday Ubuntu 11.10 avec BFS

Le point majeur à noter est qu'avec BFS, sélectionner et nanosommeiller induisent uniquement la "pénalité" pour un faible nombre de threads, mais qu'il semble induire une "pénalité" similaire (sinon plus) que celle observée avec CFS pour une valeur supérieure. le nombre de fils.

utime Ubuntu 11.10 utiliser Ubuntu 11.10 avec BFS

L'autre point intéressant est que le temps système semble être plus faible avec BFS qu'avec CFS. Encore une fois, cela commence à marcher sur de la glace mince en raison de la grossièreté des données, mais une différence semble être présente et ce résultat correspond au test de boucle de sélection de processus simple de 50 processus a montré moins d'utilisation du processeur avec BFS qu'avec CFS .

stime Ubuntu 11.10 stime Ubuntu 11.10 avec BFS

La conclusion que je tire de ces deux points est que BFS ne résout pas le problème mais semble au moins réduire ses effets dans certains domaines.

Conclusion

Comme indiqué précédemment, je ne pense pas que ce soit un problème avec l'ordonnanceur lui-même, mais avec l'interaction entre les mécanismes de sommeil et l'ordonnanceur. Je considère que cette utilisation accrue du processeur dans les processus qui devraient être en veille et utilisant peu ou pas de processeur est une régression à partir de CentOS 5.6 et un obstacle majeur pour tout programme qui souhaite utiliser une boucle d'événements ou un mécanisme de sondage.

Y a-t-il d'autres données que je peux obtenir ou des tests que je peux exécuter pour aider à diagnostiquer davantage le problème?

Mise à jour du 29 juin 2012

J'ai simplifié un peu le programme de test et je peux le trouver ici (le message commençait à dépasser la limite de longueur, j'ai donc dû le déplacer).


3
Wow, une analyse approfondie - mais avec autant de données, la question d'origine devient plus floue pour moi. Pouvez-vous le résumer 1) un seul test 2) une seule distribution 3) deux noyaux différents 4) le ralentissement de 15%? Si votre hypothèse dans le dernier paragraphe est correcte, il est temps de commencer à différencier les sources du noyau, mais il semble que les autres variables devraient être éliminées en premier.
ckhan

J'ai ajouté quelques sorties de l'application de test et je fais maintenant la comparaison par paires pour essayer de faciliter la digestion de toutes les informations.
Dave Johansen

J'ai essayé de jeter un œil à ce bugzilla, mais Redhat dit qu'il s'agit d'un "bugzilla interne et non visible par le public". Y a-t-il eu des mises à jour à ce sujet?

Je suis nouveau dans tout le bug de RedHat, donc c'est peut-être quelque chose que j'ai fait (ou pas fait) lors de la création du bug qui a fait ça, mais la seule mise à jour que j'ai entendue jusqu'à présent est une mise à jour d'un paramètre qui le fait se comporter mieux avec des processeurs hyper threadés, mais pas encore de vrai correctif.
Dave Johansen

2
CFS est le planificateur tout à fait équitable? Cela semble intéressant - j'ai également rencontré un problème de performances avec une application basée sur java sur SLES11 SP2. La différence (vers SP1) est le changement dans CFS ...
Nils

Réponses:


1

Selon les notes de version de SLES 11 SP2, cela pourrait être un changement introduit dans la façon dont CFS est implémenté.

Étant donné que SLES 11 SP2 est la version SLES actuelle, ce comportement est toujours valide (comme il semble pour tous les noyaux 3.x).

Ce changement était prévu - mais pourrait avoir de «mauvais» effets secondaires. Peut-être que l'une des solutions de contournement décrites vous aide ...


Il semble qu'il y ait un problème avec le lien et le bon est ici , mais je vais essayer ces solutions de contournement et voir si elles améliorent les performances.
Dave Johansen

Avez-vous d'autres nouvelles à ce sujet?
vonbrand

@vonbrand Vous devez probablement demander à Dave ...
Nils
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.