Novita` del kernel 2.6.23
authorSimone Piccardi <piccardi@gnulinux.it>
Wed, 10 Oct 2007 14:14:52 +0000 (14:14 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Wed, 10 Oct 2007 14:14:52 +0000 (14:14 +0000)
fileadv.tex
prochand.tex

index e881d60111e12615ad2844a78a38e18491f94d1b..ee802fb4fee414c3e308c4744f4db1789dfa1405 100644 (file)
@@ -2937,13 +2937,15 @@ semplicemente un ``\textsl{dimezzamento}'' di \func{sendfile}.\footnote{nel
   sarebbe altro che la lettura degli stessi su un buffer seguita dalla
   relativa scrittura, cosa che in questo caso si dovrebbe eseguire con due
   chiamate a \func{splice}.} In realtà le due system call sono profondamente
-diverse nel loro meccanismo di funzionamento; \func{sendfile} infatti, come
-accennato, non necessita affatto di avere a disposizione un buffer interno,
-perché esegue un trasferimento diretto di dati; questo la rende in generale
-molto più efficiente, ma anche limitata nelle sue applicazioni, dato che
-questo tipo di trasferimento è possibile solo in casi specifici.\footnote{e
-  nel caso di Linux questi sono anche solo quelli in cui essa può essere
-  effettivamente utilizzata.}
+diverse nel loro meccanismo di funzionamento;\footnote{questo fino al kernel
+  2.6.23, dove \func{sendfile} è stata reimplementata in termini di
+  \func{splice}, pur mantenendo disponibile la stessa interfaccia verso l'user
+  space.} \func{sendfile} infatti, come accennato, non necessita di avere a
+disposizione un buffer interno, perché esegue un trasferimento diretto di
+dati; questo la rende in generale più efficiente, ma anche limitata nelle sue
+applicazioni, dato che questo tipo di trasferimento è possibile solo in casi
+specifici.\footnote{e nel caso di Linux questi sono anche solo quelli in cui
+  essa può essere effettivamente utilizzata.}
 
 Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
   realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
@@ -3559,7 +3561,7 @@ mancanza di spazio disco.
 
 % TODO documentare \func{fallocate}, introdotta con il 2.6.23
 % vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
-
+% http://kernelnewbies.org/Linux_2_6_23
 
 %\subsection{L'utilizzo delle porte di I/O}
 %\label{sec:file_io_port}
index d3e89f5984f7359f6ccd75b8b96e8b8cdfb10d7f..7301bae11403ff1815edfe13b2c8085766f2aa72 100644 (file)
@@ -3297,7 +3297,6 @@ dato che in Linux questo intervallo di tempo 
 questa funzione ritorna sempre un valore di 150 millisecondi, e non importa
 specificare il PID di un processo reale.
 
-
 Come accennato ogni processo che usa lo scheduling real-time può rilasciare
 volontariamente la CPU; questo viene fatto attraverso la funzione
 \funcd{sched\_yield}, il cui prototipo è:
@@ -3317,8 +3316,12 @@ l'esecuzione non sar
 in modalità \textit{fifo}, per permettere l'esecuzione degli altri processi
 con pari priorità quando la sezione più urgente è finita.
 
+% TODO: con il 2.6.23 il comportamento è stato leggermente modificato ed è
+% stato introdotto /proc/sys/kernel/sched_compat_yield da mettere a 1 per aver
+% la compatibilità con il precedente.
 
-\subsection{Il controllo dello \textit{scheduler} per i sistemi multiprocessore}
+\subsection{Il controllo dello \textit{scheduler} per i sistemi
+  multiprocessore}
 \label{sec:proc_sched_multiprocess}
 
 Infine con il supporto dei sistemi multiprocessore sono state introdotte delle