Elevato utilizzo della CPU con CFS?


25

Ho fatto una domanda precedente per cercare di isolare la fonte di un aumento dell'utilizzo della CPU quando si sposta un'applicazione da RHEL 5 a RHEL 6. L'analisi che ho fatto per questo sembra indicare che è stata causata dal CFS nel kernel. Ho scritto un'applicazione di prova per provare e verificare se questo era il caso (applicazione di prova originale rimossa per adattarsi al limite di dimensioni, ma ancora disponibile in repository git .

L'ho compilato con il seguente comando su RHEL 5:

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

Ho quindi giocato con i parametri fino a quando il tempo di esecuzione per iterazione era di circa 1 ms su un Dell Precision m6500.

Ho ottenuto il seguente risultato su 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

E quanto segue su 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

In entrambe le versioni, questi risultati riguardavano quello che mi aspettavo con il tempo medio per ridimensionamento dell'iterazione relativamente lineare. Ho quindi ricompilato -DSLEEP_TYPE=1e ottenuto i seguenti risultati su 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

E i seguenti risultati su 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

Su RHEL 5, i risultati erano circa ciò che mi aspettavo (4 thread impiegavano il doppio del tempo a causa della sospensione di 1 ms ma gli 8 thread impiegavano lo stesso tempo poiché ogni thread ora è inattivo per circa la metà del tempo, e ancora abbastanza aumento lineare).

Tuttavia, con RHEL 6, il tempo impiegato con 4 fili è aumentato di circa il 15% in più rispetto al raddoppio previsto e il caso di 8 fili è aumentato di circa il 45% in più rispetto al leggero aumento previsto. L'aumento del caso a 4 thread sembra che RHEL 6 stia effettivamente dormendo per una manciata di microsecondi più di 1 ms mentre RHEL 5 dorme solo circa 900 noi, ma ciò non spiega l'aumento inaspettatamente grande di 8 e 40 astucci filettati.

Ho visto tipi di comportamento simili con tutti e 3 i valori -DSLEEP_TYPE. Ho anche provato a giocare con i parametri dello scheduler in sysctl, ma nulla sembrava avere un impatto significativo sui risultati. Qualche idea su come posso diagnosticare ulteriormente questo problema?

AGGIORNAMENTO: 2012-05-07

Ho aggiunto le misurazioni dell'utilizzo della CPU dell'utente e del sistema da / proc / stat // task // stat come output del test per cercare di ottenere un altro punto di osservazione. Ho anche riscontrato un problema con il modo in cui venivano aggiornate la media e la deviazione standard che è stata introdotta quando ho aggiunto il ciclo di iterazione esterno, quindi aggiungerò i nuovi grafici con la media corretta e le misurazioni della deviazione standard. Ho incluso il programma aggiornato. Ho anche fatto un repository git per tenere traccia del codice ed è disponibile qui.

#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;
}

Ho eseguito nuovamente i test su un Dell Vostro 200 (CPU dual core) con diverse versioni del sistema operativo. Mi rendo conto che molti di questi avranno diverse patch applicate e non saranno "puro codice del kernel", ma questo è stato il modo più semplice per eseguire i test su diverse versioni del kernel e ottenere confronti. Ho generato grafici con gnuplot e ho incluso la versione del bugzilla su questo problema .

Tutti questi test sono stati eseguiti con il seguente comando con il seguente script e questo 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

Ecco il riassunto di ciò che ho osservato. Questa volta li confronterò a coppie perché penso che sia un po 'più informativo in questo modo.

CentOS 5.6 vs CentOS 6.2

Il tempo di wall clock (gettimeofday) per iterazione su CentOS 5.6 è più vario di 6.2, ma questo ha senso dal momento che il CFS dovrebbe fare un lavoro migliore nel dare ai processi uguale tempo della CPU con risultati più coerenti. È anche abbastanza chiaro che CentOS 6.2 è più preciso e coerente nella quantità di tempo per cui dorme con i diversi meccanismi di sonno. gettimeofday CentOS 5.6 gettimeofday CentOS 6.2

La "penalità" è sicuramente evidente su 6.2 con un basso numero di thread (visibile su gettimeofday e grafici temporali dell'utente) ma sembra essere ridotto con un numero maggiore di thread (la differenza nel tempo dell'utente potrebbe essere solo una cosa contabile dal momento che il le misurazioni del tempo dell'utente sono così ovviamente).

utime CentOS 5.6 utime CentOS 6.2

Il diagramma del tempo di sistema mostra che i meccanismi di sospensione in 6.2 stanno consumando più sistema di quanto non abbiano fatto in 5.6, il che corrisponde ai risultati precedenti del semplice test di 50 processi che chiamano select consumando una quantità non banale di CPU su 6.2 ma non 5.6 .

stime CentOS 5.6 stime CentOS 6.2

Qualcosa che ritengo degno di nota è che l'uso di sched_yield () non induce la stessa penalità vista dai metodi sleep. La mia conclusione da ciò è che non è il programmatore stesso a essere la fonte del problema, ma l'interazione dei metodi di sospensione con il programmatore è il problema.

Ubuntu 7.10 vs Ubuntu 8.04-4

La differenza nella versione del kernel tra questi due è inferiore a quella di CentOS 5.6 e 6.2, ma copre ancora il periodo di tempo in cui è stato introdotto CFS. Il primo risultato interessante è che la selezione e il sondaggio sembrano essere gli unici meccanismi di sospensione che hanno la "penalità" su 8.04 e che la penalità continua con un numero di thread maggiore rispetto a quanto visto con CentOS 6.2.

prendimeofday Ubuntu 7.10 prendimeofday Ubuntu 8.04-4

Il tempo dell'utente per la selezione e il sondaggio e Ubuntu 7.10 sono irragionevolmente bassi, quindi questo sembra essere una sorta di problema contabile che esisteva allora, ma credo che non sia pertinente al problema / discussione corrente.

utime Ubuntu 7.10 utime Ubuntu 8.04-4

Il tempo di sistema sembra essere più alto con Ubuntu 8.04 che con Ubuntu 7.10 ma questa differenza è molto meno distinta rispetto a quanto visto con CentOS 5.6 vs 6.2.

stime Ubuntu 7.10 stime Ubuntu 8.04-4

Note su Ubuntu 11.10 e Ubuntu 12.04

La prima cosa da notare qui è che i grafici per Ubuntu 12.04 erano paragonabili a quelli dell'11.10, quindi non mostrano per evitare inutili ridondanze.

Nel complesso, i grafici per Ubuntu 11.10 mostrano lo stesso tipo di tendenza osservata con CentOS 6.2 (che indica che si tratta di un problema del kernel in generale e non solo di un problema RHEL). L'unica eccezione è che il tempo di sistema sembra essere un po 'più alto con Ubuntu 11.10 che con CentOS 6.2, ma ancora una volta, la risoluzione su questa misura è molto ovvia, quindi penso che qualsiasi conclusione diversa da "sembra essere un po' più alta "sarebbe calpestare il ghiaccio sottile.

Ubuntu 11.10 vs Ubuntu 11.10 con BFS

Un PPA che utilizza BFS con il kernel Ubuntu è disponibile su https://launchpad.net/~chogydan/+archive/ppa e questo è stato installato per generare questo confronto. Non sono riuscito a trovare un modo semplice per eseguire CentOS 6.2 con BFS, quindi ho corso con questo confronto e poiché i risultati di Ubuntu 11.10 si confrontano così bene con CentOS 6.2, credo che sia un confronto equo e significativo.

prendimeofday Ubuntu 11.10 prendimeofday Ubuntu 11.10 con BFS

Il punto più importante è che con BFS solo selezionare e nanosleep inducono la "penalità" con un numero basso di thread, ma che sembra indurre una "penalità" simile (se non maggiore) come quella vista con CFS per un livello superiore numero di thread.

utime Ubuntu 11.10 utime Ubuntu 11.10 con BFS

L'altro punto interessante è che il tempo di sistema sembra essere inferiore con BFS che con CFS. Ancora una volta, questo sta iniziando a calpestare il ghiaccio sottile a causa della grossolanità dei dati, ma sembra che vi sia una certa differenza e questo risultato corrisponde al semplice test del ciclo di selezione a 50 processi ha mostrato un minore utilizzo della CPU con BFS rispetto a CFS .

stime Ubuntu 11.10 stime Ubuntu 11.10 con BFS

La conclusione che traggo da questi due punti è che BFS non risolve il problema ma almeno sembra ridurne gli effetti in alcune aree.

Conclusione

Come precedentemente affermato, non credo che questo sia un problema con lo stesso programmatore, ma con l'interazione tra i meccanismi del sonno e lo scheduler. Considero questo aumento dell'utilizzo della CPU in processi che dovrebbero essere inattivi e che utilizzano poca o nessuna CPU una regressione da CentOS 5.6 e un grosso ostacolo per qualsiasi programma che desideri utilizzare un loop di eventi o uno stile di polling del meccanismo.

Ci sono altri dati che posso ottenere o test che posso eseguire per aiutare a diagnosticare ulteriormente il problema?

Aggiornamento del 29 giugno 2012

Ho semplificato un po 'il programma di test e può essere trovato qui (il post stava iniziando a superare il limite di lunghezza, quindi ho dovuto spostarlo).


3
Caspita, analisi approfondita - ma con così tanti dati la domanda originale mi sta diventando più confusa. Puoi ridurlo 1) un singolo test 2) una singola distro 3) due diversi kernel 4) il rallentamento del 15%? Se la tua ipotesi nell'ultimo paragrafo è corretta, è tempo di iniziare a diffondere i sorgenti del kernel, ma sembra che le altre variabili debbano essere eliminate per prime.
ckhan,

Ho aggiunto alcuni output dall'applicazione di test e ora faccio il confronto in coppia per provare a semplificare un po 'il digest di tutte le informazioni.
Dave Johansen,

Ho provato a dare un'occhiata a quel bugzilla, ma Redhat sta dicendo che è "un bugzilla interno e non visibile al pubblico". Ci sono stati aggiornamenti su questo?

Sono nuovo a tutto ciò che riguarda il bug RedHat, quindi potrebbe essere stato qualcosa che ho fatto (o non fatto) quando ho creato il bug che lo ha fatto, ma l'unico aggiornamento che ho sentito finora è un aggiornamento a un parametro che lo fa comportare meglio con i processori hyper thread, ma non è stata ancora risolta una vera correzione.
Dave Johansen,

2
CFS è lo scheduler completamente corretto? Sembra interessante: ho riscontrato un problema di prestazioni anche con un'applicazione basata su Java su SLES11 SP2. La differenza (rispetto a SP1) è la modifica di CFS ...
Nils,

Risposte:


1

Secondo le note di rilascio di SLES 11 SP2 questo potrebbe essere un cambiamento introdotto nel modo in cui CFS viene implementato.

Poiché SLES 11 SP2 è l'attuale versione di SLES, questo comportamento è ancora valido (come sembra per tutti i kernel 3.x).

Questo cambiamento era previsto, ma potrebbe avere effetti collaterali "cattivi". Forse una delle soluzioni alternative descritte ti aiuta ...


Sembra che ci sia qualcosa di sbagliato nel collegamento e quello corretto sia qui , ma proverò quelle soluzioni alternative per vedere se aiutano le prestazioni.
Dave Johansen,

Altre notizie su questo?
vonbrand,

@vonbrand Probabilmente devi chiedere a Dave ...
Nils,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.