Note di rilascio

Note di rilascio di HFTKernel 7.3.x.

Esplora la serie del kernel 7.3.x dalla più recente alla più vecchia, con le modifiche upstream più rilevanti per esecuzione CPU prevedibile, rete stabile, gestione del tempo precisa, virtualizzazione, comportamento della memoria e code di latency misurabili.

Leggi HFTKernel 7.3.3 Apri la documentazione del kernel
Serie di versioni

Registro pubblico delle modifiche

Note di rilascio

Ogni voce si concentra sulle modifiche upstream che supportano gli obiettivi principali di HFTKernel: jitter minimo, tail latency controllata, percorso dati stabile, gestione del tempo precisa e comportamento misurabile sotto pressione.

HFTKernel 7.3.3

Ordine dei pacchetti migliorato, avanzamento I/O più affidabile e polling più leggero

Ultima voce della serie 7.3.x

Base upstream: Linux 7.3.3. Modifiche cumulative: Linux 7.3.2 e 7.3.3, rispetto a 7.3.1. Data di rilascio upstream: 6 novembre 2026 per entrambe le versioni.

Trasmissione ordinata con code sotto pressione

Lo scheduler di rete conserva l'ordine dei pacchetti quando un driver restituisce NETDEV_TX_BUSY. I pacchetti rimessi in coda tornano all'inizio della lista dei pacchetti in attesa nel loro ordine originale.

Nel test upstream con quattro flussi TCP su una coppia veth con una pfifo qdisc, il throughput è aumentato da circa 40 a 76 Gbps. La modifica ha eliminato circa 1.3 milioni di segmenti fuori ordine e da 15,000 a 37,000 ritrasmissioni per ogni intervallo di test di 15 secondi.

Offload hardware VLAN coerente

Con reorder_hdr=off, i frame idonei passano il proprio tag VLAN ai metadata di inserimento della NIC, mantenendo il layout previsto all'egress del dispositivo VLAN. Questo mantiene l'inserimento VLAN hardware compatibile con checksum offload e segmentation offload, inclusi i percorsi interessati di packet-socket e AF_XDP in copy-mode.

NAPI busy polling consapevole delle deadline

io_uring limita il busy polling all'intervallo di attesa rimanente. Quando una deadline assoluta è già trascorsa, il budget di polling diventa zero, consentendo all'attesa di terminare rapidamente.

Le voci NAPI tracciate dinamicamente ora scadono dopo 60 secondi di inattività. I ring attivi a lungo smettono di riesaminare identificatori di coda obsoleti, mantenendo il polling concentrato sul traffico recente.

Wakeup affidabili del lavoro differito e avanzamento delle completion

IORING_SETUP_DEFER_TASKRUN pubblica lo stato sleep del task in attesa prima di esporre il suo wakeup credit. I producer possono notificare in modo affidabile il consumer quando arriva nuovo task work locale. Il ciclo di attesa guidato da BPF segue lo stesso ordine.

Quando le completion in overflow in attesa non trovano spazio nella completion queue, io_uring restituisce il controllo a userspace affinché l'applicazione possa svuotarla. Questo fornisce un percorso esplicito di avanzamento per le completion queue con voci di dimensioni diverse.

Avanzamento più robusto per i consumer real-time

La task-work queue lockless protegge la pubblicazione in due fasi del producer con una breve sezione a preemption disabilitata. Un consumer SCHED_FIFO che condivide una CPU con un producer a priorità inferiore osserva una pubblicazione completata, senza interrompere il producer a metà dell'aggiornamento tramite preemption.

Le attese asincrone su private futex preparano l'hash privato del processo prima di registrare il waiter. I wakeup rimangono allineati con l'hash attivo durante la successiva creazione di thread e le modifiche alla configurazione dell'hash.

Meno attività SQPOLL superflua

SQPOLL può entrare in sleep mentre un ring è disabilitato, anche quando sono già state preparate submission entry. L'abilitazione del ring risveglia il thread di polling. Le applicazioni possono predisporre la configurazione iniziale senza occupare una CPU a controllare ripetutamente lavoro non ancora abilitato.

Limiti meglio applicati ai worker I/O asincroni

io_uring risolve il file di destinazione prima di assegnare lavoro a io-wq. Le operazioni forced-async su regular file e block device rispettano i limiti dei bounded worker, inclusi i limiti configurati con IORING_REGISTER_IOWQ_MAX_WORKERS.

Le scritture buffered sullo stesso regular file sono coordinate tramite hashing basato sull'inode, riducendo i worker che competono per lo stesso inode lock. L'identità del file viene fissata quando la richiesta entra nella work queue.

Buffer di ricezione affidabili su scala maggiore

La ricezione zero-copy calcola gli offset dei buffer con aritmetica a 64 bit prima dello shift. Le completion entry identificano il buffer corretto oltre i primi 4 GiB di un'area di ricezione registrata, mantenendo allineati consumo e refill.

Per i provided buffer incrementali e i receive bundle multi-buffer, l'avanzamento parziale viene completato prima che un'altra richiesta possa riutilizzare la memoria rimanente. Le applicazioni ricevono la lunghezza effettivamente trasferita e proseguono da quel limite; queste operazioni MSG_WAITALL possono restituire un risultato breve.

Clock domain corretti per gli aggiornamenti dei timeout assoluti

Gli aggiornamenti dei timeout assoluti usano il clock associato al timer esistente quando convertono il time namespace del chiamante nel tempo dell'host. CLOCK_MONOTONIC, CLOCK_BOOTTIME e CLOCK_REALTIME mantengono le rispettive semantiche.

Questo mantiene coerenti le deadline asincrone per i servizi che usano time namespace e diversi clock domain dei timeout.

Accounting della memoria più completo

I metadata task-to-ring e le personality XArrays vengono addebitati ai memory cgroup. Anche i metadata dei buffer registrati e i resource node partecipano all'accounting memcg, mantenendo rappresentata nei budget dei servizi la memoria I/O del kernel.

Il teardown di XArray libera i nodi interni vuoti lasciati dai tentativi di inserimento non riusciti. La creazione e la pulizia ripetute dei ring rilasciano queste allocazioni di metadata e i relativi addebiti.

Ciclo di vita delle pagine HugeTLB più robusto

Il percorso di fault HugeTLB anonimo completa gli aggiornamenti dello stato del folio e il suo sblocco prima di rilasciare il page-table lock. L'inizializzazione rimane coordinata con le operazioni concorrenti di unmapping e page reclamation, rafforzando i mapping privati di huge page usati per grandi buffer applicativi.

Teardown coordinato di IRQ e dispositivi di timing

La pulizia dei threaded IRQ conserva irqaction finché il task work di uscita in attesa non è terminato, mantenendo il ciclo di vita delle risorse lungo il percorso di uscita anomala del thread.

Le operazioni di controllo del generatore PPS sono sincronizzate con l'unregister della sorgente. Le operazioni già in corso terminano su uno stato valido del driver e quelle successive ricevono ENODEV dopo la rimozione. Questo fornisce al software dei servizi di timing un confine chiaro nel ciclo di vita del dispositivo.

Stato dell'host KVM più coerente

Sugli host Intel VMX, le modifiche in userspace che rendono una vCPU runnable rimuovono anche, quando necessario, lo stato halt tracciato dall'hardware. Questo mantiene lo stato di esecuzione hardware allineato con il virtual-machine monitor durante i flussi di reset e riavvio.

AMD SVM aggiorna la generazione ASID in entrambi i blocchi di controllo della nested virtualization dopo un cambio di CPU fisica. Gli identificatori dello spazio di indirizzamento rimangono coordinati quando le vCPU nested si spostano tra processori.

Miglioramenti ai backend Xen aggiunti in Linux 7.3.3

L'ultimo aggiornamento cumulativo aggiunge tre miglioramenti per le distribuzioni con backend Xen. Le letture delle statistiche del block backend sono sincronizzate con il teardown del frontend. Le statistiche del network backend rimangono protette durante la pulizia delle code. La pulizia della lista multicast avviene dopo l'arresto dell'elaborazione in trasmissione e ricezione.

Insieme, queste modifiche mantengono coordinati il monitoring, lo stato della rete virtuale e il rilascio delle risorse dei backend durante la disconnessione e la riconfigurazione dei dispositivi.

Sistemi operativi supportati

Il catalogo dei pacchetti HFTKernel copre 24 target di sistemi operativi:

  • Ubuntu 20.04 / 22.04 / 24.04 / 26.04 LTS
  • Debian 11 / 12 / 13
  • Compatibili con RHEL, AlmaLinux, Rocky Linux 8 / 9 / 10
  • CentOS Stream 9 / 10
  • Fedora Linux 44
  • Amazon Linux 2023, profilo Cloud
  • ALT Linux p11 / Simply Linux 11
  • Astra Linux 1.8
  • Arch Linux base-devel
  • Base compatibile con NixOS.

Installazione con un solo comando

curl -fsSL https://hftkernel.com/install.sh | sudo bash

L'installer rileva il sistema operativo e il profilo di distribuzione, verifica il pacchetto corrispondente e lo installa. Un riavvio manuale attiva il kernel installato.

Focus della versione

Preservare l'ordine di trasmissione, mantenere l'avanzamento del lavoro asincrono, eliminare il polling superfluo e mantenere chiara l'ownership della memoria e delle risorse dei dispositivi.

Visualizza i pacchetti del sistema operativo Esamina i parametri di avvio Richiedi un profilo di avvio per la produzione Link permanente

HFTKernel 7.3.1

I/O asincrono più prevedibile, wakeup RT precisi e diagnostica affidabile dell'host

Base upstream: Linux 7.3.1. Modifiche rispetto a Linux 7.3. Data di rilascio upstream: 30 ottobre 2026.

Avanzamento tempestivo dopo le barriere drain di io_uring

Una richiesta drain autonoma ora azzera lo stato drain quando la sua completion viene sottoposta a flush e non rimane altro lavoro differito. Nell'esecuzione io-wq, questa transizione avviene sotto il ring lock prima che la completion diventi visibile in userspace.

Le richieste inviate dopo il completamento della barriera possono proseguire senza attendere che il worker rilasci l'ultimo riferimento alla richiesta. Le richieste drain collegate mantengono i propri requisiti di ordinamento.

Questo rende più prevedibili le pipeline I/O guidate dalle completion per le applicazioni che usano barriere drain.

Wakeup poll affidabili e completion multishot

Un'operazione atomica compare-and-exchange ora coordina il rilascio dell'ownership di poll con le notifiche concorrenti di retry. I wakeup in attesa rimangono visibili, consentendo all'elaborazione di proseguire senza dipendere da un evento non correlato.

Il poll multishot aggiorna inoltre correttamente il contatore di riferimenti condiviso in caso di hangup. Il passaggio finale di elaborazione degli eventi può completarsi senza iterazioni ripetute inutili, migliorando la gestione del ciclo di vita delle connessioni nelle applicazioni asincrone.

Timeout precisi della completion queue su PREEMPT_RT

Per i task RT e deadline su PREEMPT_RT, le callback di timeout della completion queue di io_uring vengono eseguite in contesto hard-interrupt. La consegna dei wakeup non dipende più dallo scheduling del timer thread a priorità inferiore.

Nel test upstream su Jetson Orin Nano, con la modifica applicata tramite backport a Linux 6.18.39-rt, il ritardo massimo è sceso da 1,040 µs a 18 µs su 40,000 deadline sotto carico SCHED_FIFO concorrente. Dopo la modifica, tutti i wakeup sono rimasti entro 100 µs di ritardo.

Gestione coerente dei provided buffer di ricezione di grandi dimensioni

Per le operazioni di ricezione non-bundled che ricavano la propria lunghezza da un provided buffer, io_uring limita la lunghezza di trasferimento selezionata a MAX_RW_COUNT.

Questo mantiene valida la lunghezza nel percorso di ritorno che usa un valore con segno, anche per provided buffer da 2 GiB o più, rispettando il limite esistente per la dimensione del trasferimento. Rafforza la gestione dei buffer di ricezione per le applicazioni che usano grandi regioni riutilizzabili.

Arresto meglio coordinato dei worker asincroni

Il percorso di uscita di io-wq applica una memory barrier dopo aver pubblicato il proprio flag di uscita. L'arresto e il task work concorrente che crea i worker rispettano l'ordinamento richiesto, anche sulle architetture con ordinamento debole.

Questo rafforza il teardown ordinato e il riavvio dei servizi che usano worker pool io_uring.

Anche la cancellazione delle richieste IORING_OP_WAITID è idempotente: i tentativi ripetuti riconoscono lo stato di cancellazione esistente senza accumulare riferimenti aggiuntivi. Questo mantiene coerenti le richieste asincrone di supervisione dei processi durante la cancellazione.

Meno lavoro inutile durante il teardown dei PID namespace

Durante la pulizia del namespace, il process reaper maschera i wakeup delle notifiche task-work mentre attende la terminazione dei processi figli e il rilascio dei PID.

Può rimanere in attesa fino all'evento rilevante del ciclo di vita, anziché rientrare ripetutamente nel proprio percorso di attesa. Questo riduce l'attività CPU evitabile nelle interazioni interessate tra arresto dei container e livepatch.

Visibilità affidabile degli IRQ per CPU sugli host di grandi dimensioni

/proc/interrupts ora emette la propria intestazione CPU ogni volta che viene generato il primo record, inclusi i tentativi successivi all'espansione del sequence buffer.

La corrispondenza tra CPU e contatori rimane intatta sui sistemi con molti core. Questo supporta un parsing affidabile degli IRQ, la verifica del posizionamento e il monitoraggio delle CPU isolate e di housekeeping.

Configurazione e teardown del tracing più puliti

La configurazione degli istogrammi ora rimuove i trigger field-variable creati automaticamente quando il comando complessivo non riesce. Il tracing attivo corrisponde alla configurazione accettata e la strumentazione temporanea viene rimossa, anziché continuare a contare gli eventi.

La pulizia degli istogrammi field-variable conserva il riferimento stabile all'event-file, senza dipendere dal ciclo di vita di un altro istogramma. Questo migliora la creazione, la modifica e la rimozione ripetute delle sessioni diagnostiche.

Il parsing degli event-filter rifiuta inoltre le espressioni logiche incomplete prima dell'esecuzione. Questo rafforza la configurazione automatizzata di tracefs e dei tracepoint perf.

Diagnostica postmortem più completa

La raccolta dei core dump è protetta dalle interruzioni TIF_NOTIFY_SIGNAL durante il trasferimento dei dati tramite pipe e socket. Le notifiche di io_uring e di altri produttori task-work non interrompono più questi percorsi di raccolta.

Questo preserva i dati diagnostici per un'analisi dettagliata dello stato dell'applicazione, dei mapping e dell'I/O in sospeso.

Validazione coerente delle quote DAMON

Gli obiettivi delle quote DAMOS vengono validati nel core DAMON prima dell'applicazione. I valori obiettivo pari a zero vengono rifiutati attraverso il percorso di commit comune e l'errore viene propagato ai chiamanti.

Per le distribuzioni che usano la gestione della memoria basata su DAMON, questo fornisce un punto di validazione coerente per la configurazione delle policy delle quote.

Build out-of-tree affidabili del benchmark DMA

dma_map_benchmark ora viene compilato nella directory di output selezionata quando viene specificato O=.

Il benchmark si integra nelle pipeline di build che separano gli alberi dei sorgenti dagli strumenti generati, supportando una preparazione ripetibile della diagnostica DMA.

Sistemi operativi supportati e installazione

HFTKernel supporta 24 OS target tra Ubuntu, Debian, piattaforme compatibili con RHEL, AlmaLinux, Rocky Linux, CentOS Stream, Fedora, Amazon Linux, Arch Linux, distribuzioni compatibili con NixOS, ALT Linux p11 / Simply Linux 11 e Astra Linux 1.8. Amazon Linux 2023 usa il profilo Cloud.

Installazione con un solo comando:

curl -fsSL https://hftkernel.com/install.sh | sudo bash

L'installer seleziona il pacchetto corrispondente al sistema operativo e il profilo di distribuzione e verifica l'integrità dei pacchetti.

Focus della versione

La base Linux 7.3.1 rafforza l'avanzamento dell'I/O, la consegna dei timeout real-time, la gestione del ciclo di vita dei processi e la coerenza diagnostica. Queste modifiche sostengono l'obiettivo di HFTKernel di fornire un host prevedibile e misurabile per le applicazioni sensibili alla latency.

Visualizza i pacchetti del sistema operativo Esamina i parametri di avvio Richiedi un profilo di avvio per la produzione Link permanente

HFTKernel 7.3

Letture temporali predisposte, gestione della memoria più snella e nuove funzionalità di rete CXL

Base upstream: Linux 7.3. Data di rilascio upstream: 18 ottobre 2026.

Focus: funzionalità introdotte con la base Linux 7.3 per distribuzioni sensibili alla latency.

Dati vDSO precaricati per un avvio applicativo prevedibile

Il mapping generico dei dati vDSO può ora essere popolato da mlockall(). La rimozione del flag VM_IO consente alla fase di preparazione della memoria di creare le voci corrispondenti nelle tabelle delle pagine prima dell'elaborazione sensibile alla latency.

Per le applicazioni che usano letture temporali assistite da vDSO, questo sposta un page fault first-touch evitabile nella preparazione iniziale. L'autore upstream ha osservato circa 20 µs per l'intero percorso di eccezione del page fault sulla macchina di prova.

Rafforza la preparazione di motori di trading, utilizzatori di timestamp e processi di misurazione che precaricano esplicitamente i propri insiemi di lavoro.

Minore contesa sul lock LRU durante il reclaim della memoria

Il reclaim LRU classico ricava ora dai contatori vmstat i costi di bilanciamento delle scansioni anonime e dei file. Campionamento e decadimento dei costi usano un lock dedicato per lruvec invece di acquisire ripetutamente il lock che protegge le operazioni sulle liste LRU. L'aggregazione della gerarchia sostituisce inoltre gli aggiornamenti ripetuti dei costi ai livelli genitori.

Nel test upstream di pressione sulla memoria con 176 core e 256 GB, l'attesa aggregata sul lock LRU è scesa da circa 4.23 secondi a 1.66 secondi in una finestra di registrazione di 30 secondi, una riduzione del 61%, con tassi di scansione e reclaim simili.

Per le distribuzioni con LRU classico, riduce la contesa tra contabilità del reclaim e operazioni che gestiscono effettivamente le pagine.

Maggiore conservazione del codice eseguibile con MGLRU

MGLRU promuove i folio di file eseguibili mappati dopo il primo utilizzo osservato. Sia l'invecchiamento delle tabelle delle pagine sia il controllo dei riferimenti riconoscono i mapping eseguibili durante l'aggiornamento dello stato delle pagine.

Offre una maggiore protezione dal reclaim al codice applicativo e delle librerie condivise usato di recente. Favorisce una residenza del codice più costante per i servizi con MGLRU sotto pressione sulla memoria.

Meno lavoro superfluo di contabilizzazione della pressione in cgroup v2

Il sottosistema vmpressure salta il percorso di notifica userspace di cgroup v1 quando gira sotto cgroup v2. Il reclaim evita contabilità, lock, invii a workqueue e attraversamenti dei genitori inutilizzati.

Il percorso di pressione dei socket TCP/SCTP nel kernel rimane attivo e il monitoraggio userspace della pressione di cgroup v2 continua tramite PSI. Elimina lavoro infrastrutturale ridondante conservando i segnali di pressione usati da rete e gestione dei servizi.

Sezioni critiche workqueue più brevi

L'elaborazione workqueue seleziona il worker da risvegliare mantenendo pool->lock, poi esegue il risveglio dopo averlo rilasciato. Le operazioni di risveglio dello scheduler non estendono più la sezione critica del pool condiviso nei percorsi interessati di accodamento e lavoro concatenato.

In un microbenchmark upstream su NVIDIA Grace ARM64 con unbound workqueues limitate a NUMA, il throughput è aumentato da 719,794 a 794,049 elementi di lavoro al secondo, con latency di accodamento P95 inferiore del 10.3%.

Migliora la gestione del lavoro in background conteso sulle CPU di housekeeping e nell'infrastruttura di supporto.

Servizi gestiti dallo scheduler più reattivi

Lo scheduling cgroup della classe fair passa a una singola runqueue di selezione delle attività per CPU mantenendo la distribuzione dei pesi dei gruppi. EEVDF migliora inoltre lo scheduling delle attività con intervalli brevi e il bilanciamento NOHZ preferisce core completamente inattivi.

Queste modifiche riguardano gateway, monitoraggio, orchestrazione e servizi di housekeeping gestiti dallo scheduler. CPU affinity esplicita rimane il meccanismo di collocazione per i thread di trading dedicati.

Ricezione zero-copy io_uring più scalabile

Il sottosistema di ricezione zero-copy io_uring acquisisce provisioning dinamico delle aree di memoria e miglioramenti coordinati del refill. Il refill delle pagine grandi scala con l'allocazione sottostante, le voci compatibili vengono unite e testa e coda del ring di refill occupano linee di cache separate. La memorizzazione della coda riduce ulteriormente gli accessi allo stato condiviso.

Queste modifiche migliorano la gestione della memoria di ricezione e riducono l'overhead del refill per le applicazioni che usano io_uring ZCRX, inclusi dati di mercato ad alta frequenza e carichi di elaborazione di rete.

Supporto alla trasmissione Solarflare assistita da CXL nella base upstream

Linux 7.3 unisce l'infrastruttura CXL Type-2 e l'integrazione del driver Solarflare per i dispositivi compatibili della famiglia SFC9100. CONFIG_SFC_CXL abilita il percorso del driver per CTPIO su CXL.mem, con hardware CXL compatibile e firmware che riconosce CXL.

Il driver verifica le capacità del dispositivo CXL, crea una regione di memoria CTPIO da 256 MiB e la mappa con semantica write-combining. Fornisce l'abilitazione nel kernel di un percorso di trasmissione host-NIC assistito da CXL.

Per una configurazione HFTKernel Hardware corrispondente, l'integrazione combina CONFIG_SFC, CONFIG_CXL_BUS e CONFIG_SFC_CXL con server, adattatore e firmware compatibili. Crea un'opzione mirata di ottimizzazione hardware per la trasmissione sensibile alla latency.

Controllo ampliato dei clock hardware

Il driver DPLL ZL3073x acquisisce supporto per il clock hardware PTP, esponendo lettura del tempo, regolazione temporale, di frequenza e di fase tramite i callback appropriati. Le operazioni disponibili seguono lo stato corrente del canale, inclusi funzionamento NCO e inseguimento del riferimento.

Amplia le opzioni di temporizzazione hardware disponibili tramite le interfacce Linux standard e facilita l'integrazione dei dispositivi supportati nell'infrastruttura di gestione dei clock.

Gestione della rete cloud più scalabile

Driver di rete software selezionati, inclusi veth, ipvlan e tunnel, acquisiscono deregistrazione dei dispositivi per namespace di rete. Anche gli aggiornamenti delle regole di routing abbandonano il lock RTNL globale. Queste modifiche riducono la serializzazione condivisa durante le operazioni del ciclo di vita della rete e delle politiche di routing.

Il supporto BIG TCP si estende ai tunnel UDP come VXLAN e Geneve. Batch di segmentazione interni più grandi offrono un'opzione aggiuntiva di efficienza per distribuzione massiva dei dati e replay sugli overlay supportati, preservando la MTU configurata sul collegamento.

Diagnostica multicast più utile

RTM_GETMULTICAST riporta un conteggio di utenti per gruppo. Il software di monitoraggio può esaminare l'utilizzo dei gruppi multicast tramite netlink, migliorando la visibilità sullo stato delle sottoscrizioni sugli host che ricevono dati di mercato multicast.

Profilazione delle allocazioni più efficiente

La profilazione delle allocazioni di memoria acquisisce un'interfaccia ioctl binaria per /proc/allocinfo. I filtri per modulo, funzione, file e riga possono essere applicati prima dell'aggregazione dei contatori per CPU, così le query diagnostiche elaborano solo i punti di allocazione corrispondenti.

Nel test upstream su Intel Xeon Platinum 8481C con 224 CPU logiche, una query per un file specifico ha ridotto il tempo CPU di sistema da 22 ms a 1 ms. Rende le analisi mirate della memoria più leggere e adatte alla raccolta automatizzata.

I nuovi contatori pgrotate_anon e pgrotate_file rendono visibile il lavoro di reclaim che non libera immediatamente pagine. Supportano la diagnostica sia di LRU classico sia di MGLRU.

Strumenti di misurazione inclusi

HFTKernel include cpujitter per intervalli di mancata esecuzione CPU e code di latency, memjitter per allocazione, first-touch e comportamento dell'insieme di lavoro, e irqjitter per l'analisi dell'attività IRQ e softIRQ.

Insieme a latency applicativa, contatori di rete, stato dei clock hardware e telemetria della memoria, questi strumenti rendono osservabile l'intera infrastruttura.

Focus della versione

La base Linux 7.3 porta avanti tre priorità di HFTKernel: preparare più stato prima dell'avvio del carico, ridurre la contesa nei percorsi condivisi del kernel ed esporre un controllo migliore su rete, memoria e temporizzazione.

Visualizza i pacchetti del sistema operativo Esamina i parametri di avvio Richiedi un profilo di avvio per la produzione Link permanente

Filosofia dei rilasci

Stabilità upstream, politiche specifiche per il carico di lavoro e risultati misurabili

HFTKernel parte da una precisa versione stabile di Linux, registra toolchain e identità della build, applica il profilo Cloud o Hardware selezionato, include cpujitter e memjitter con l'ambiente di esecuzione e valida il risultato come versione immutabile.

Base precisaSorgenti Linux stabili verificati e versione del kernel fissata.
Profilo controllatoPolitiche CPU, memoria, rete, gestione del tempo e isolamento abbinate alla piattaforma.
Pacchetti nativiBundle DEB, RPM o TGZ per la matrice di produzione supportata.
Consegna verificata con misurazionicpujitter e memjitter forniscono evidenze ripetibili sulle code.

Pianificazione della distribuzione

Valuta la versione rispetto alla tua topologia CPU, NIC, memoria e temporizzazione.

La selezione dei pacchetti è solo il primo passo. Il risultato in produzione dipende da parametri di avvio, affinità durante l'esecuzione, collocazione delle code, progettazione PTP/PHC, politica di memoria e piano di misurazione controllato.

Richiedi un profilo di avvio per la produzione Leggi il riferimento ai parametri di avvio