La contromossa di Torvalds al BFS di Con Kolivas

[Ansa89]

Non ho capito bene il senso del messaggio, comunque mi pare tutto corretto quello che hai postato: dentro la sezione "Control Group support" non c'è il supporto per il "Group CPU scheduler" proprio perché hai applicato la patch ck e attivato lo scheduler bfs.

[Mario Vanoni]

Non ho capito bene il senso del messaggio, comunque mi pare tutto corretto quello che hai postato: dentro la sezione "Control Group support" non c'è il supporto per il "Group CPU scheduler" proprio perché hai applicato la patch ck e attivato lo scheduler bfs.

Ma contiene parti dello scheduler, che -ck2 ignora!
Facendo un sar 1 (tty) su tre macchine, sono molto piu` calme che con -ck2 originale.

[shark1500]

Offtopic:

Offtopic: PS: "ogniuno" non esiste, meglio se correggi.

Offtopic:

Si puo` scrivere in entrambi i modi (appena controllato per sicurezza).

[slux]

Vedo che il thread ha decisamente destato l'interesse di molti.
Volevo riportare le impressioni di Con Kolivas dal suo blog riguardo a questa nuova patch.
http://ck-hack.blogspot.com/2010/11/cre ... mment.html
A quanto sembra Kolivas,ha sparato a zero su tutta la linea.La patch,secondo lui, sembra essere efficiente solo per i grandi carichi di lavoro (vedi esempio make -j64),ma porta delle gravi regressioni per i carichi normali di tutti i giorni.
Voi che avete provato entrambe le soluzioni,trovate che Con abbia ragione?

[Blallo]

sono tornato alle ck
avevo sottoposto la patch ad un carico webkit + emesene + liferea
tutto sotto openbox
con 512 mb di ram
dove ck rende usabile tutto, la patch "ufficiale" fallisce (caricamenti eterni ogni 5 minuti, impossibilità di compilare qualcosa mentre navigo..ecc)

Ck potrebbe aver ragione

[Mario Vanoni]

Vedo che il thread ha decisamente destato l'interesse di molti.
Volevo riportare le impressioni di Con Kolivas dal suo blog riguardo a questa nuova patch.
http://ck-hack.blogspot.com/2010/11/cre ... mment.html
A quanto sembra Kolivas,ha sparato a zero su tutta la linea.La patch,secondo lui, sembra essere efficiente solo per i grandi carichi di lavoro (vedi esempio make -j64),ma porta delle gravi regressioni per i carichi normali di tutti i giorni.
Voi che avete provato entrambe le soluzioni,trovate che Con abbia ragione?

Core 2 Dual 1866MHz, 4096kB L2 cache e 4GB RAM, con 2 tty ed un X attivi:
make -j 32 bzImage, macchina non piu` usabile
make -j 4 bzImage, macchina usabile, ma piu` lenta di
make -j 2 bzImage, macchina usabilissima!

[shark1500]

La patch e` molto semplice di per se`, e (almeno cosi` ad occhio, non ho avuto modo di provarla) dovrebbe migliorare in caso di grossi workloads e restare uguale in caso di workload normali (come da utente desktop).

Purtroppo non ho tempo per provarla, se qualcuno di voi puo` fare dei test piu` o meno accurati sarebbe interessante.

[Mario Vanoni]

Ho provato su tre macchine 2.6.36.1,
il kernel e` molto lontano dalle prestazioni del 2.6.36-ck2.
Infatti nella LKML parlano gia` del 2.6.36.2.

[Ansa89]

Ho provato su tre macchine 2.6.36.1,
il kernel e` molto lontano dalle prestazioni del 2.6.36-ck2.
Infatti nella LKML parlano gia` del 2.6.36.2.

Hai provato anche il 2.6.36.1-ck2?

[Mario Vanoni]

Ho provato su tre macchine 2.6.36.1,
il kernel e` molto lontano dalle prestazioni del 2.6.36-ck2.
Infatti nella LKML parlano gia` del 2.6.36.2.

Hai provato anche il 2.6.36.1-ck2?

Un solo Hunk, ma funziona perfettamente su tre macchine, grazie per la dritta.