From 02950a8e6544100a795b38e88f30d1f97ad67494 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Wed, 10 Oct 2007 14:14:52 +0000 Subject: [PATCH] Novita` del kernel 2.6.23 --- fileadv.tex | 18 ++++++++++-------- prochand.tex | 7 +++++-- 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/fileadv.tex b/fileadv.tex index e881d60..ee802fb 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -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} diff --git a/prochand.tex b/prochand.tex index d3e89f5..7301bae 100644 --- a/prochand.tex +++ b/prochand.tex @@ -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 -- 2.30.2