Google è sicuramente l’azienda che dispone del maggior numero di computer con linux al mondo.
Mike Waychison è intervenuto durante il Linux Kernel Summit per spiegare come viene utilizzato internamente all’azienda. Tutte le modifiche al kernel, 300000 linee, vengono portate all’ultima versione ogni 17 mesi e quando tutto funziona vengono introdotte le nuove funzionalità ogni sei mesi.
I sistemi di google hanno 16-32 core e fanno girare fino a 5000 thread. Un numero non da poco che pone qualche problema all’infrastruttura di base del kernel. Addirittura portano alla nuova versione del kernel il vecchio scheduler O(1).
Per il 2010 le cose dovrebbero cambiare con release interne più ravvicinate e con un dialogo più stretto con gli sviluppatori. Sono molto interessanti i problemi che google sta cercando di risolvere. Alla domanda come mai il codice non fosse pubblico la risposta indicava come uno dei problemi il codice scritto piuttosto male e portato avanti dal 2.4.18.
Via | Lwn
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, chi siamo
© 2004-2011 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
Azaroth
09 nov 2009 - 11:53 - #1Decisamente un articolo sciatto, scritto di fretta, senza riferimenti e che non dice niente. La qualità di questo blog inizia a calare come quella del resto del network?
firefox87
09 nov 2009 - 13:45 - #2Quoto Azaroth.
Il 2.418 finale sarebbe la versione del kernel 2.4.18!
Ormai conviene direttamente andare alla fonte per leggere l’articolo e non leggere quello scritto dalla “redazione”.
Cos’è successo ai vari blog in italia?Sembrano più degli aggregatori di notizie con un commento per articolo. :( tristezza!
omg-linux
09 nov 2009 - 14:00 - #3per favore ripubblicate questo articolo scritto in modo chiaro ed esauriente.
e linkate la fonte.
markux
09 nov 2009 - 14:18 - #4firefox87 m’hai tolto le parole di bocca:
“Cos’è successo ai vari blog in italia? Sembrano più degli aggregatori di notizie con un commento per articolo.”
wondeland
09 nov 2009 - 17:11 - #5uò essere singola organizzazione che gestisce più sistemi Linux di Google. Ma la comunità di sviluppo del kernel conosce poco su come Google utilizza Linux e che tipo di problemi si incontrano lì. Google Mike Waychison viaggiato a Tokyo per aiutare a far luce su questa situazione, il risultato è stato una vista interessante su quello che serve per far girare Linux in questo ambiente estremamente esigente.
Mike ha iniziato la discussione dando agli sviluppatori una bella risata: sembra che Google gestisce il codice del kernel con Perforce. Si è scusato per quello. Vi è un unico albero che tutti gli sviluppatori si impegnano a. Circa ogni 17 mesi, Google ribasa i suoi lavori a una versione attuale per grandi linee, quello che segue è una lunga lotta per far funzionare di nuovo tutto. Una volta fatto, interno “funzione” stampa accade circa ogni sei mesi.
Questo modo di fare le cose è ben lungi dall’essere ideale, significa che Google è molto indietro rispetto alla linea principale e ha un tempo difficile parlare con la comunità di sviluppo del kernel sui suoi problemi.
Ci sono circa 30 ingegneri che lavorano su kernel di Google. Attualmente essi tendono a verificare i cambiamenti nella struttura, quindi dimenticate di loro per i prossimi 18 mesi. Questo porta ad alcune questioni concrete di manutenzione, gli sviluppatori spesso hanno la minima idea di ciò che è effettivamente in albero di Google fino a quando non si rompe.
E c’è una partita in quell’albero. Google ha iniziato con il kernel 2.4.18 - ma patch oltre 2000 immagini, l’inserimento di 492.000 linee di codice. Tra le altre cose, che backport supporto a 64 bit in quel kernel. Alla fine si sono trasferiti a 2.6.11, soprattutto perché avevano bisogno di supporto SATA. Un kernel 2.6.18-base seguita, e si stanno ora lavorando alla preparazione di un kernel 2.6.26-based per la distribuzione nel prossimo futuro. Sono attualmente conducendo 1208 patch per 2.6.26, l’inserimento di quasi 300.000 linee di codice. Circa il 25% di tali patch, le stime Mike, sono backport di nuove funzionalità.
Ci sono piani per cambiare tutto questo; gruppo Google kernel sta cercando di arrivare a un punto in cui si possa lavorare meglio con la comunità del kernel. Stanno muovendosi a git per la gestione del codice sorgente, e gli sviluppatori manterranno il loro cambiamenti nel loro alberi stessi. Quegli alberi saranno rapportati al kernel mainline comunicati ogni trimestre, che dovrebbe, si spera, motivare gli sviluppatori di rendere il codice più gestibile e più strettamente allineata con il kernel a monte.
Linus ha chiesto: perché non sono queste le patch a monte? È perché Google è imbarazzato da loro, o è roba un segreto che non vogliono rivelare, o è una questione di problemi di processo interno? La risposta è stata semplicemente “sì”. Alcuni di questo codice è roba brutta che è stata portata avanti dal kernel 2.4.18. Ci sono dubbi anche internamente su quanto di questo materiale sarà effettivamente utile per il resto del mondo. Ma, forse, forse la metà circa di questo codice potrebbe essere upstreamed fine.
Quanto 3 / 4 del codice di Google consiste di modifiche al kernel core, supporto per le periferiche è una parte relativamente piccola del totale.
Google ha un certo numero di “punti dolore”, che rendono il lavoro con la comunità più difficile. Tenere il passo con il kernel a monte è difficile - si muove troppo velocemente. C’è anche un problema reale con gli sviluppatori di distacco di una patch, poi viene chiesto di rielaborare in modo che si trasforma in un progetto molto più grande. Alan Cox, che ha una risposta semplice a quello: la gente sarà sempre chiedere di più, ma a volte la cosa giusta da fare è semplicemente dire loro “no”.
Nel settore della schedulazione della CPU, Google ha trovato il passaggio al scheduler completamente giusto essere doloroso. In realtà, era un problema che finalmente hanno portato avanti il vecchio O (1) scheduler e può essere eseguito in 2.6.26. Cambiamenti nella semantica di sched_yield () ha creato dolore, soprattutto con la user-space di bloccaggio che Google utilizza. High-thread priorità può rendere un pasticcio di bilanciamento del carico, anche se eseguito per periodi di tempo molto breve. E questioni di bilanciamento del carico: Google gestisce qualcosa come 5.000 discussioni su sistemi con 16-32 core.
Sul versante della gestione della memoria, i kernel più nuovi cambiato la gestione dei bit dirty, portando a writeout eccessivamente aggressivo. Il sistema potrebbe facilmente entrare in una situazione in cui un sacco di piccole I / O operazioni generate da kswapd riempirebbe le code richiesta, fame writeback altri; questo particolare problema dovrebbe essere fissata dal pro-cambiamenti writeback BDI in 2.6.32.
Come osservato in precedenza, Google gestisce i sistemi con un sacco di thread non - una modalità insolita di funzionamento in generale. Una cosa hanno scoperto è che l’invio di segnali ad un grande gruppo thread può portare ad un sacco di eseguire la tesi di blocco coda. Essi hanno anche problemi con la tesi per il semaforo mmap_sem; un lettore dormire in grado di bloccare uno scrittore che, a sua volta, blocca altri lettori, portando il tutto a una battuta d’arresto. Il kernel deve essere fissata a non aspettare di I / O con quel semaforo in attesa.
Google fa un sacco di utilizzo del out-of-memoria (OOM) killer di pare sistemi di back sovraccarico. Che possono creare problemi, però, quando i processi di partecipazione mutex incontrare il killer OOM. Mike si chiede perché il kernel cerca così difficile, e non solo in mancanza di richieste di allocazione di memoria, quando diventa troppo stretto.
Così che cosa è Google facendo con tutto quello che il codice del kernel? Cercano molto difficile da ottenere il massimo da ogni macchina che hanno, in modo da stipare un sacco di lavoro su ciascuno. Questo lavoro è suddiviso in tre classi: “latenza sensibili”, che ottiene garanzie a breve termine delle risorse “, lotto di produzione”, che ha garanzie per periodi più lunghi, e di “best effort”, che non riceve garanzie a tutti. Questa separazione delle classi avviene in parte attraverso la separazione di ogni macchina in un gran numero di falsi “nodi NUMA.” Posti di lavoro specifici sono poi assegnato a uno o più di tali nodi. Una cosa che ha aggiunto da parte di Google è “NUMA-aware VFS LRU” - la gestione della memoria virtuale che si concentra su specifici nodi NUMA. Nick Piggin osservò che ha lavorato su una cosa del genere e avrebbe voluto vedere il codice di Google.
Vi è una classe speciale di pianificazione SCHED_GIDLE che è una classe veramente minimo, se non c’è ricambio CPU disponibili, posti di lavoro in quella classe non verrà eseguito a tutti. Per evitare problemi di inversione di priorità, processi SCHED_GIDLE hanno la loro priorità è temporaneamente aumentata quando dormono nel kernel (ma non se sono preempted nello spazio utente). In rete è gestita con la disciplina di fare la coda HTB, aumentata con un mazzo di logica di controllo della larghezza di banda. Per i dischi, si sta lavorando su proporzionale I / O di programmazione.
Oltre a ciò, un sacco di codice di Google è là per il monitoraggio. Sono chiamate a controllare tutte le disco e il traffico di rete, registrare, e utilizzarlo per analizzare le loro operazioni in seguito. Ganci sono state aggiunte per far loro associare tutte le operazioni di I / O torna alle domande - tra cui I writeback asincrono / O. Mike è stato chiesto se potevano usare tracepoints per questo compito, la risposta è stata “sì”, ma, naturalmente, Google sta utilizzando il suo programma proprio oggi.
Google ha un sacco di importanti obiettivi per il 2010, che includono:
Sono entusiasta di limiti di CPU, che sono destinati a dare un accesso prioritario alla latenza compiti sensibili pur mantenendo i compiti da assumere il sistema completamente.
RPC-scheduling CPU a conoscenza; ciò comporta l’ispezione del traffico RPC in entrata per determinare quale processo si sveglierà in risposta e quanto sia importante che il risveglio è.
Una iniziativa è in ritardo relativi orari. Per la maggior parte dei fili, la latenza non è poi così importante. Ma il kernel tenta di eseguire immediatamente quando i messaggi vengono in RPC, questi messaggi non tendono ad essere equamente distribuiti tra le CPU, il carico di gravi problemi di bilanciamento. Così thread può essere aggiunto per la pianificazione di ritardo, quando un risveglio arriva, non sono immediatamente messi nella coda di esecuzione. Invece, l’attesa fino al prossimo mondiale di bilanciamento del carico dell’operazione, prima di diventare veramente funzionante.
Iniezione ciclo di inattività: high-power management della larghezza di banda in modo che possano funzionare le loro macchine sul bordo della fusione - ma non oltre.
Controller di memoria migliore sono sulla lista, anche contabili per l’utilizzo della memoria del kernel.
“La memoria non in linea”. Mike ha osservato che è sempre più difficile acquistare memoria che funziona davvero, soprattutto se si vuole andare a buon mercato. Quindi hanno bisogno di essere in grado di impostare le pagine non parte. Il lavoro HWPOISON possono aiutarli in questo settore.
Hanno bisogno di pagine dinamiche enormi, che possono essere assemblati e ripartiti su richiesta.
Sul lato rete, c’è un desiderio di migliorare il supporto per ricevere-scaling lato - a dirigere il traffico in entrata alle code specifici. Hanno bisogno di essere in grado di considerazione per il software di interrupt il tempo e lo attribuiscono a compiti specifici - l’elaborazione di rete può spesso comportare grandi quantità di trasformazione softirq. Hanno lavorato sul controllo di congestione meglio, gli algoritmi sono venuti con “non sono sicuro di Internet”, ma funzionano bene nel data center. E “pacing TCP” rallenta il traffico in uscita per evitare il sovraccarico switch.
Per lo stoccaggio, vi è molto interesse nel ridurre block-overhead strato in modo che possa tenere il passo con flash ad alta velocità. Uso di Flash per l’accelerazione del disco nello strato di blocco è sulla lista. Che stanno guardando in-flash strati kernel di traduzione, anche se è stato suggerito che potrebbe essere migliore per gestire questa logica direttamente nel filesystem.
Mike ha concluso con un paio di “problemi interessanti”. Uno di questi è che Google vorrebbe un modo per pin metadati del filesystem in memoria. Il problema qui è in grado di tenuta del tempo necessario per il servizio richieste di I / O. Il tempo necessario per leggere un blocco dal disco è noto, ma se i metadati in questione non è nella memoria, più di un disco I / O operazione può essere richiesto. Che rallenta le cose in modo inopportuno. Google sta ricevendo intorno a questo leggendo i dati di file direttamente da dispositivi disco crudo nello spazio utente, ma vorrei smettere di farlo.
L’altro problema è ridurre l’overhead della chiamata di sistema per la fornitura di consulenza cache (con fadvise ()) per il kernel. Non è chiaro esattamente quale fosse il problema qui.
Tutto sommato, è stato visto come una delle sessioni più successo, con la comunità kernel imparare molto su uno dei suoi principali clienti. Se i piani di Google per diventare più orientati alla comunità giungeranno a buon fine, il risultato dovrebbe essere un kernel migliore per tutti.
FONTE IN LINGUA INGLESE:
http://www.chineselinuxuniversity.net/articles/29860.shtml
efwf
10 nov 2009 - 17:40 - #6Una roba tradotta e rimescolata… che m-erda :