On Wed, Dec 20, 2006 at 10:10:57AM +0100, Daniel Cordey wrote:
> Oui, mais ainsi tu multiplie (en theorie) le nombre de CS... As-tu mesure
> l'impact en terme d'overhead suplemetaire ? C'est vrai que pour un driver,
> 10ms c'est trop long... Mais j'imagine qu'ensuite ton pilote etait charge
> comme un module kernel et ne restait pas en user-space, non ?
Sisi, le 80% de la logique restait en user-space, c'est plus rapide à
debugger, plus sûr, plus flexible. Le développement de code kernel est
quelque chose que l'on essaie d'éviter. Le moins il y a de code
là-dedans le mieux c'est (c'est pour cela que je trouve bien les
scanners avec le code en user-space, via interface générique; et
dommageable les pilotes graphiques dans le kernel).
Donnons le détail, ça me rappellera de bons souvenirs:
il s'agissait d'un logiciel en 4 parties:
- un pilote kernel pour une carte SCSI QLogic, mais en mode `target'
en C
y compris un firmware spécial accélérant le traitement des
commandes et séquences de commandes
- un pilote kernel `relay', qui servait les commandes reçues par la
carte SCSI (provenant d'un autre PC), et gérait des buffers
partagés contigus de `grande' taille.
- un programme en user-space, en C, qui appelait un ioctl(2) dans
le pilote `relay', l'associait au pilote `target', puis se mettait
en attente d'un événement (via un ioctl(2)).
le programme consistait en plusieurs instances de processus
communiquant ensemble (un gérant les communications avec le
pilote, le deuxième les configurations par le CGI, et ensuite un
nombre de processus dépendant du nombre d'objets gérés par le
système: on y a mis jusqu'à 10 lecteurs de cassette).
une fois un événement reçu de `relay', il se réveillait,
traitait la commande SCSI (évt. en mettant à disposition un ou
plusieurs buffers partagés via mmap(2)), faisait des
entrées/sorties normales, etc
event = grab_event(target_fd,
buffer_address,
TARGET_EVENT_TYPE_NEW_COMMAND,
&data,
&size,
&event_id,
TRUE);
/* ici traitement de la commande, des I/O éventuelles */
- un petit CGI en Perl qui gérait l'état du programme en Perl
La performance obtenue était d'environ 20 MByte/s en écriture et en
lecture. Le délai d'activation n'était pas si grave, car on utilisait
un certain parallélisme (un peu comme le pipeline d'un processeur).
Mais à 10ms c'était quand même trop. Avec 1ms on ne voyait pas de perte
de performance particulière, même en charge (p.ex. compresseur ou
chiffrement en parallèle).
Je n'ai jamais implémenté la version `entièrement en kernel' ou
`entièrement en C', car cela n'avait pas de justification.
Le matériel était PC bas-de-gamme-monté soi-même de 2002. Sauf erreur un
Duron 900 avec 64 MB de mémoire.
Le logiciel a eu deux applications principales, dont une vendue:
- système de sauvegarde avec compression et chiffrement optionnels
(la performance était limitée à max 2-3 MByte/s avec le processeur
retenu, suffisant pour la performance d'un SDT-11'000 de l'époque)
- RAID3 sur 5 lecteurs de cassettes en parallèle
Une version modifiée du logiciel pouvait proposer n'importe quel fichier
ou block-device Linux (y compris LVM ou RAID). Cette version-là n'a
jamais été vendue mais a été utilisée en interne. La performance obtenue
était d'environ 90 MByte/s traversant en RAID5, avec certes du matériel
haut de gamme (deux bus PCI 64 bits séparés reliés en AGP). Mais
cette version-là avait la logique entièrement dans `relay' (sauf les
commandes SCSI les plus lentes comme INQUIRY, etc), pas en
user-space
J'avais dû modifier du code dans le buffer-cache de Linux, j'avais été
très prudent.
Le soft doit traîner dans mes archives (style dans anciens projets
chez cril.ch), normalement.
Le problème est que tout cela a été développé il y a fort longtemps, et
qu'il faudrait changer énormément de choses pour être compatible.
D'un autre côté, les interfaces programmatiques disponibles ont
également évolué. P.ex. quand j'ai développé mon système de fichiers
hiérarchique (HSM, mfs), l'infrastructure FUSE (Filesystem In Userspace)
n'existait pas ... j'avais dû l'écrire. Ou bien l'interface `direct IO'.
Donc peut-être que certaines choses seraient plus simples.
_______________________________________________
gull mailing list
gull@lists.alphanet.ch
http://lists.alphanet.ch/mailman/listinfo/gull
