¿Alto uso de CPU con CFS?

25

Hice una pregunta anterior para tratar de aislar la fuente de un aumento en el uso de la CPU al mover una aplicación de RHEL 5 a RHEL 6. El análisis que hice para eso parece indicar que está siendo causado por el CFS en el núcleo. Escribí una aplicación de prueba para tratar de verificar si este era el caso (la aplicación de prueba original se eliminó para ajustarse al límite de tamaño, pero aún está disponible en git repo .

Lo compilé con el siguiente comando en RHEL 5:

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

Luego jugué con los parámetros hasta que el tiempo de ejecución por iteración fue de aproximadamente 1 ms en un Dell Precision m6500.

Obtuve el siguiente resultado en 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

Y lo siguiente en 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

En ambas versiones, estos resultados fueron aproximadamente lo que esperaba con la cantidad promedio de tiempo por escala de iteración relativamente lineal. Luego volví a compilar -DSLEEP_TYPE=1y obtuve los siguientes resultados en 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

Y los siguientes resultados en 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

En RHEL 5, los resultados fueron aproximadamente lo que esperaba (4 hilos toman el doble de tiempo debido al sueño de 1 ms, pero los 8 hilos toman la misma cantidad de tiempo ya que cada hilo está durmiendo durante aproximadamente la mitad del tiempo, y todavía bastante aumento lineal).

Sin embargo, con RHEL 6, el tiempo necesario con 4 hilos aumentó aproximadamente un 15% más que la duplicación esperada y el caso de 8 hilos aumentó aproximadamente un 45% más que el ligero aumento esperado. El aumento en el caso de 4 hilos parece ser que RHEL 6 está durmiendo durante unos pocos microsegundos más de 1 ms, mientras que RHEL 5 solo duerme alrededor de 900 us, pero esto no explica el aumento inesperadamente grande en los 8 y 40 cajas de hilo.

Vi tipos de comportamiento similares con todos los valores 3 -DSLEEP_TYPE. También intenté jugar con los parámetros del planificador en sysctl, pero nada parecía tener un impacto significativo en los resultados. ¿Alguna idea sobre cómo puedo diagnosticar aún más este problema?

ACTUALIZACIÓN: 2012-05-07

Agregué mediciones del uso de CPU del usuario y del sistema desde / proc / stat // tareas // stat como resultado de la prueba para intentar obtener otro punto de observación. También encontré un problema con la forma en que se actualizaban la media y la desviación estándar que se introdujo cuando agregué el bucle de iteración externo, por lo que agregaré los nuevos gráficos que tienen las medidas corregidas de la media y la desviación estándar. He incluido el programa actualizado. También hice un repositorio git para rastrear el código y está disponible aquí.

#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 <[email protected]>)
#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;
}

Volví a ejecutar las pruebas en un Dell Vostro 200 (CPU de doble núcleo) con varias versiones diferentes del sistema operativo. Me doy cuenta de que varios de estos tendrán diferentes parches aplicados y no serán "código de kernel puro", pero esta fue la forma más sencilla de ejecutar las pruebas en diferentes versiones del kernel y obtener comparaciones. Genere tramas con gnuplot y he incluido la versión del bugzilla sobre este tema .

Todas estas pruebas se ejecutaron con el siguiente comando con el siguiente script y este comando ./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

Aquí está el resumen de lo que observé. Los compararé en pares esta vez porque creo que es un poco más informativo de esa manera.

CentOS 5.6 vs CentOS 6.2

El tiempo de reloj de pared (gettimeofday) por iteración en CentOS 5.6 es más variado que 6.2, pero esto tiene sentido ya que el CFS debería hacer un mejor trabajo al dar a los procesos el mismo tiempo de CPU que da como resultado resultados más consistentes. También está bastante claro que CentOS 6.2 es más preciso y consistente en la cantidad de tiempo que duerme con los diferentes mecanismos para dormir. gettimeofday CentOS 5.6 gettimeofday CentOS 6.2

La "penalización" es definitivamente evidente en 6.2 con un número bajo de subprocesos (visible en gettimeofday y en los gráficos de tiempo del usuario) pero parece reducirse con un mayor número de subprocesos (la diferencia en el tiempo del usuario puede ser algo contable ya que el las medidas de tiempo del usuario son tan claras

utime CentOS 5.6 utime CentOS 6.2

El diagrama de tiempo del sistema muestra que los mecanismos de suspensión en 6.2 están consumiendo más sistema que en 5.6, lo que corresponde con los resultados anteriores de la prueba simple de 50 procesos que simplemente llaman a select que consume una cantidad no trivial de CPU en 6.2 pero no 5.6 .

Stime CentOS 5.6 Stime CentOS 6.2

Algo que creo que vale la pena tener en cuenta es que el uso de sched_yield () no induce la misma penalización que los métodos de suspensión. Mi conclusión de esto es que no es el programador en sí mismo el origen del problema, sino la interacción de los métodos de suspensión con el programador que es el problema.

Ubuntu 7.10 vs Ubuntu 8.04-4

La diferencia en la versión del kernel entre estos dos es menor que la de CentOS 5.6 y 6.2, pero aún abarcan el período de tiempo cuando se introdujo el CFS. El primer resultado interesante es que seleccionar y sondear parecen ser los únicos mecanismos de suspensión que tienen la "penalización" en 8.04 y esa penalización continúa a un mayor número de hilos que lo que se vio con CentOS 6.2.

gettimeofday Ubuntu 7.10 gettimeofday Ubuntu 8.04-4

El tiempo de usuario para seleccionar y sondear y Ubuntu 7.10 es irrazonablemente bajo, por lo que parece ser algún tipo de problema contable que existía entonces, pero creo que no es relevante para el tema / discusión actual.

utime Ubuntu 7.10 utime Ubuntu 8.04-4

El tiempo del sistema parece ser mayor con Ubuntu 8.04 que con Ubuntu 7.10, pero esta diferencia es MUCHO menos distinta de lo que se vio con CentOS 5.6 vs 6.2.

stime Ubuntu 7.10 stime Ubuntu 8.04-4

Notas sobre Ubuntu 11.10 y Ubuntu 12.04

Lo primero que hay que tener en cuenta aquí es que las tramas para Ubuntu 12.04 eran comparables a las de 11.10, por lo que no se muestran para evitar redundancias innecesarias.

En general, las tramas para Ubuntu 11.10 muestran el mismo tipo de tendencia que se observó con CentOS 6.2 (lo que indica que este es un problema del núcleo en general y no solo un problema de RHEL). La única excepción es que el tiempo del sistema parece ser un poco más alto con Ubuntu 11.10 que con CentOS 6.2, pero una vez más, la resolución en esta medición es muy clara, así que creo que cualquier conclusión que no sea "parece ser un poco más alta". "estaría pisando sobre hielo delgado.

Ubuntu 11.10 vs Ubuntu 11.10 con BFS

Puede encontrar un PPA que usa BFS con el kernel de Ubuntu en https://launchpad.net/~chogydan/+archive/ppa y se instaló para generar esta comparación. No pude encontrar una manera fácil de ejecutar CentOS 6.2 con BFS, así que realicé esta comparación y, dado que los resultados de Ubuntu 11.10 se comparan muy bien con CentOS 6.2, creo que es una comparación justa y significativa.

gettimeofday Ubuntu 11.10 gettimeofday Ubuntu 11.10 con BFS

El punto principal de la nota es que con BFS solo seleccionar y nano-sueño inducen la "penalización" en un número bajo de subprocesos, pero que parece inducir una "penalización" similar (si no una mayor) como la que se ve con CFS para un mayor Número de hilos.

utime Ubuntu 11.10 utime Ubuntu 11.10 con BFS

El otro punto interesante es que el tiempo del sistema parece ser menor con BFS que con CFS. Una vez más, esto está comenzando a pisar hielo delgado debido a la aspereza de los datos, pero parece haber alguna diferencia y este resultado coincide con la simple prueba de ciclo de selección de 50 procesos mostró menos uso de CPU con BFS que con CFS .

stime Ubuntu 11.10 stime Ubuntu 11.10 con BFS

La conclusión que extraigo de estos dos puntos es que BFS no resuelve el problema, pero al menos parece reducir sus efectos en algunas áreas.

Conclusión

Como se dijo anteriormente, no creo que este sea un problema con el planificador en sí, sino con la interacción entre los mecanismos de suspensión y el planificador. Considero que este aumento en el uso de la CPU en procesos que deberían estar inactivos y usar poca o ninguna CPU es una regresión de CentOS 5.6 y un obstáculo importante para cualquier programa que quiera usar un bucle de eventos o un estilo de mecanismo de sondeo.

¿Hay algún otro dato que pueda obtener o pruebas que pueda ejecutar para ayudar a diagnosticar el problema?

Actualización el 29 de junio de 2012

Simplifiqué un poco el programa de prueba y puedo encontrarlo aquí (la publicación comenzaba a exceder el límite de longitud, así que tuve que moverlo).

Dave Johansen
fuente
3
Wow, un análisis exhaustivo, pero con tantos datos, la pregunta original me resulta más confusa. ¿Se puede reducir 1) una sola prueba 2) una única distribución 3) dos núcleos diferentes 4) la desaceleración del 15%? Si su hipótesis en el último párrafo es correcta, es hora de comenzar a diferenciar las fuentes del kernel, pero siente que las otras variables deberían eliminarse primero.
ckhan
Agregué algunos resultados de la aplicación de prueba y ahora hago la comparación en pares para intentar facilitar un poco la digestión de toda la información.
Dave Johansen
Traté de echar un vistazo a ese bugzilla, pero Redhat dice que es "un bugzilla interno y no visible para el público". ¿Ha habido alguna actualización sobre esto?
Soy nuevo en todo el asunto del error de RedHat, por lo que puede haber sido algo que hice (o no hice) al crear el error que hizo eso, pero la única actualización que he escuchado hasta ahora es una actualización de un parámetro que hace que se comporte mejor con procesadores hiperprocesados, pero aún no hay una solución real.
Dave Johansen el
2
CFS es el planificador completamente justo? Esto suena interesante: me encontré con un problema de rendimiento con una aplicación basada en Java en SLES11 SP2 también. La diferencia (a SP1) es el cambio en CFS ...
Nils

Respuestas:

1

De acuerdo con las notas de lanzamiento de SLES 11 SP2, esto podría ser un cambio introducido en la forma en que se implementa el CFS.

Dado que SLES 11 SP2 es la versión actual de SLES, este comportamiento sigue siendo válido (como parece para todos los núcleos 3.x).

Este cambio fue intencionado, pero podría tener efectos secundarios "malos". Quizás una de las soluciones descritas le ayude ...

Nils
fuente
Parece que hay algo mal con el enlace y el correcto está aquí , pero probaré esas soluciones y veré si ayudan al rendimiento.
Dave Johansen el
¿Alguna noticia más sobre esto?
vonbrand
@vonbrand Probablemente tienes que preguntarle a Dave ...
Nils