Pour avoir des informations détaillées sur les processus, je lis le
contenu de /proc/<PID>/usage. Le problème est que je ne comprends pas le
sens concret de certaines informations... J'ai collé la structure
correspondante ci-dessous. Je m'interroge notamment sur:
- text/data/kernel page fault sleep time,
- minor/major page faults,
- swaps,
- input/output blocks.
En fait, je cherche mieux savoir ce que fait un processus (est-ce qu'il
est sur les CPU, est-ce qu'il attend des données des disques, est-ce qu'il
attend des données de la mémoire ou du swap, est-ce qu'il s'est fait
swapper...).
Peut-être y a-t-il d'autres façons de savoir tout ça?
Partie intéressante de /usr/include/sys/procfs.h (Solaris 7 à 9)
<<<<<
/*
* Resource usage. /proc/<pid>/usage /proc/<pid>/lwp/<lwpid>/lwpusage
*/
typedef struct prusage {
id_t pr_lwpid; /* lwp id. 0: process or defunct */
int pr_count; /* number of contributing lwps */
timestruc_t pr_tstamp; /* current time stamp */
timestruc_t pr_create; /* process/lwp creation time stamp */
timestruc_t pr_term; /* process/lwp termination time stamp */
timestruc_t pr_rtime; /* total lwp real (elapsed) time */
timestruc_t pr_utime; /* user level cpu time */
timestruc_t pr_stime; /* system call cpu time */
timestruc_t pr_ttime; /* other system trap cpu time */
timestruc_t pr_tftime; /* text page fault sleep time */
timestruc_t pr_dftime; /* data page fault sleep time */
timestruc_t pr_kftime; /* kernel page fault sleep time */
timestruc_t pr_ltime; /* user lock wait sleep time */
timestruc_t pr_slptime; /* all other sleep time */
timestruc_t pr_wtime; /* wait-cpu (latency) time */
timestruc_t pr_stoptime; /* stopped time */
timestruc_t filltime[6]; /* filler for future expansion */
ulong_t pr_minf; /* minor page faults */
ulong_t pr_majf; /* major page faults */
ulong_t pr_nswap; /* swaps */
ulong_t pr_inblk; /* input blocks */
ulong_t pr_oublk; /* output blocks */
ulong_t pr_msnd; /* messages sent */
ulong_t pr_mrcv; /* messages received */
ulong_t pr_sigs; /* signals received */
ulong_t pr_vctx; /* voluntary context switches */
ulong_t pr_ictx; /* involuntary context switches */
ulong_t pr_sysc; /* system calls */
ulong_t pr_ioch; /* chars read and written */
ulong_t filler[10]; /* filler for future expansion */
} prusage_t;
>>>>>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
DINH Viêt Hoà
- text/data/kernel page fault sleep time,
le temps d'attente entre le moment où le processus a demandé une page au noyau et le moment où il l'a reçu, et ceci pour des pages dans les segments de données précisés.
- minor/major page faults,
une faute de page un accès à une page alors qu'elle n'est pas réellement en mémoire physique. La différence entre une faute mineure et majeure est un accès au disque (cas de la faute majeure). Exemple de faute mineure : un malloc() et lors du premier accès à la zone de mémoire données, la page est allouée en mémoire physique et initialisée à zéro => faute mineure de page Exemple de faute majeure : accès à une page mémoire dont les données ont été placées sur disque (fichier d'échange (swap))
- swaps,
nombre d'accès au swap
En fait, je cherche mieux savoir ce que fait un processus (est-ce qu'il est sur les CPU, est-ce qu'il attend des données des disques, est-ce qu'il attend des données de la mémoire ou du swap, est-ce qu'il s'est fait swapper...). Peut-être y a-t-il d'autres façons de savoir tout ça?
Dans quel but ?
Pourquoi ne pas utiliser les méthodes standard de profiling de programmes ?
-- DINH V. Hoa,
"on peut rouler dans une épave avec un caisson de basse" -- sunZ
- text/data/kernel page fault sleep time,
le temps d'attente entre le moment où le processus a demandé une page au
noyau et le moment où il l'a reçu, et ceci pour des pages dans les
segments de données précisés.
- minor/major page faults,
une faute de page un accès à une page alors qu'elle n'est pas réellement
en mémoire physique. La différence entre une faute mineure et majeure
est un accès au disque (cas de la faute majeure).
Exemple de faute mineure : un malloc() et lors du premier accès à la
zone de mémoire données, la page est allouée en mémoire physique et
initialisée à zéro => faute mineure de page
Exemple de faute majeure : accès à une page mémoire dont les données ont
été placées sur disque (fichier d'échange (swap))
- swaps,
nombre d'accès au swap
En fait, je cherche mieux savoir ce que fait un processus (est-ce qu'il
est sur les CPU, est-ce qu'il attend des données des disques, est-ce qu'il
attend des données de la mémoire ou du swap, est-ce qu'il s'est fait
swapper...).
Peut-être y a-t-il d'autres façons de savoir tout ça?
Dans quel but ?
Pourquoi ne pas utiliser les méthodes standard de profiling
de programmes ?
--
DINH V. Hoa,
"on peut rouler dans une épave avec un caisson de basse" -- sunZ
le temps d'attente entre le moment où le processus a demandé une page au noyau et le moment où il l'a reçu, et ceci pour des pages dans les segments de données précisés.
- minor/major page faults,
une faute de page un accès à une page alors qu'elle n'est pas réellement en mémoire physique. La différence entre une faute mineure et majeure est un accès au disque (cas de la faute majeure). Exemple de faute mineure : un malloc() et lors du premier accès à la zone de mémoire données, la page est allouée en mémoire physique et initialisée à zéro => faute mineure de page Exemple de faute majeure : accès à une page mémoire dont les données ont été placées sur disque (fichier d'échange (swap))
- swaps,
nombre d'accès au swap
En fait, je cherche mieux savoir ce que fait un processus (est-ce qu'il est sur les CPU, est-ce qu'il attend des données des disques, est-ce qu'il attend des données de la mémoire ou du swap, est-ce qu'il s'est fait swapper...). Peut-être y a-t-il d'autres façons de savoir tout ça?
Dans quel but ?
Pourquoi ne pas utiliser les méthodes standard de profiling de programmes ?
-- DINH V. Hoa,
"on peut rouler dans une épave avec un caisson de basse" -- sunZ
- text/data/kernel page fault sleep time, le temps d'attente
[...]
Merci pour ces précieuses informations!
Exemple de faute mineure : un malloc() et lors du premier accès à la zone de mémoire données, la page est allouée en mémoire physique et initialisée à zéro => faute mineure de page
Donc tous les processus devraient avoir une valeur non-nulle ici... Je ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.
En fait, je cherche mieux savoir ce que fait un processus Dans quel but ?
J'essaie de comparer des processeurs alors qu'ils sont dans des machines d'architectures différentes. Les machines ont plus ou moins de RAM (4 à 256 Go), ont des disques plus ou moins rapides (disques internes ou montages NFS)... Pour que le test soit valable (dans la mesure du possible, évidemment; je sais bien que les conditions sont très défavorables), je voudrais savoir quand mes processus ont eu besoin d'accéder aux disques, pour pouvoir éliminer ces cas-là (et recommencer avec moins de données).
Les accès aux disques que je vois et que je voudrais détecter sont: - l'accès aux données. J'essaie de forcer la mise en cache des données, en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes mes données tiennent en cache?). - l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la quantité de données traitée.
Pourquoi ne pas utiliser les méthodes standard de profiling de programmes ?
Hum... Est-ce que ces méthodes ne sont pas faire pour évaluer un programme, et non la façon dont une machine le fait tourner?
Dans mon cas, j'utilise des applications de calcul déjà écrites et figées, et je voudrais évaluer les différences de comportement sur différents processeurs, en éliminant le plus possible les autres facteurs. Je sais bien que certains facteurs ne pourront être éliminés, comme le temps d'accès à la mémoire. Mais peut-être y a-t-il un moyen d'évaluer ces influences? Je regarderai de plus près les « text/data/kernel page fault sleep time », pour voir si ça semble correspondre.
Je suis preneur de toute suggestion. Je mène ces tests en tant que simple utilisateur, et j'avoue être assez démuni... :(
- text/data/kernel page fault sleep time,
le temps d'attente
[...]
Merci pour ces précieuses informations!
Exemple de faute mineure : un malloc() et lors du premier accès à la
zone de mémoire données, la page est allouée en mémoire physique et
initialisée à zéro => faute mineure de page
Donc tous les processus devraient avoir une valeur non-nulle ici... Je
ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.
En fait, je cherche mieux savoir ce que fait un processus
Dans quel but ?
J'essaie de comparer des processeurs alors qu'ils sont dans des machines
d'architectures différentes. Les machines ont plus ou moins de RAM (4 à
256 Go), ont des disques plus ou moins rapides (disques internes ou
montages NFS)...
Pour que le test soit valable (dans la mesure du possible, évidemment;
je sais bien que les conditions sont très défavorables), je voudrais
savoir quand mes processus ont eu besoin d'accéder aux disques, pour
pouvoir éliminer ces cas-là (et recommencer avec moins de données).
Les accès aux disques que je vois et que je voudrais détecter sont:
- l'accès aux données. J'essaie de forcer la mise en cache des données,
en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais
pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes
mes données tiennent en cache?).
- l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la
quantité de données traitée.
Pourquoi ne pas utiliser les méthodes standard de profiling de
programmes ?
Hum... Est-ce que ces méthodes ne sont pas faire pour évaluer un
programme, et non la façon dont une machine le fait tourner?
Dans mon cas, j'utilise des applications de calcul déjà écrites et
figées, et je voudrais évaluer les différences de comportement sur
différents processeurs, en éliminant le plus possible les autres facteurs.
Je sais bien que certains facteurs ne pourront être éliminés, comme le
temps d'accès à la mémoire. Mais peut-être y a-t-il un moyen d'évaluer ces
influences?
Je regarderai de plus près les « text/data/kernel page fault sleep
time », pour voir si ça semble correspondre.
Je suis preneur de toute suggestion. Je mène ces tests en tant que
simple utilisateur, et j'avoue être assez démuni... :(
- text/data/kernel page fault sleep time, le temps d'attente
[...]
Merci pour ces précieuses informations!
Exemple de faute mineure : un malloc() et lors du premier accès à la zone de mémoire données, la page est allouée en mémoire physique et initialisée à zéro => faute mineure de page
Donc tous les processus devraient avoir une valeur non-nulle ici... Je ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.
En fait, je cherche mieux savoir ce que fait un processus Dans quel but ?
J'essaie de comparer des processeurs alors qu'ils sont dans des machines d'architectures différentes. Les machines ont plus ou moins de RAM (4 à 256 Go), ont des disques plus ou moins rapides (disques internes ou montages NFS)... Pour que le test soit valable (dans la mesure du possible, évidemment; je sais bien que les conditions sont très défavorables), je voudrais savoir quand mes processus ont eu besoin d'accéder aux disques, pour pouvoir éliminer ces cas-là (et recommencer avec moins de données).
Les accès aux disques que je vois et que je voudrais détecter sont: - l'accès aux données. J'essaie de forcer la mise en cache des données, en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes mes données tiennent en cache?). - l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la quantité de données traitée.
Pourquoi ne pas utiliser les méthodes standard de profiling de programmes ?
Hum... Est-ce que ces méthodes ne sont pas faire pour évaluer un programme, et non la façon dont une machine le fait tourner?
Dans mon cas, j'utilise des applications de calcul déjà écrites et figées, et je voudrais évaluer les différences de comportement sur différents processeurs, en éliminant le plus possible les autres facteurs. Je sais bien que certains facteurs ne pourront être éliminés, comme le temps d'accès à la mémoire. Mais peut-être y a-t-il un moyen d'évaluer ces influences? Je regarderai de plus près les « text/data/kernel page fault sleep time », pour voir si ça semble correspondre.
Je suis preneur de toute suggestion. Je mène ces tests en tant que simple utilisateur, et j'avoue être assez démuni... :(
- text/data/kernel page fault sleep time, le temps d'attente
[...]
Merci pour ces précieuses informations!
Exemple de faute mineure : un malloc() et lors du premier accès à la zone de mémoire données, la page est allouée en mémoire physique et initialisée à zéro => faute mineure de page
Donc tous les processus devraient avoir une valeur non-nulle ici... Je ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.
En fait, je cherche mieux savoir ce que fait un processus Dans quel but ?
J'essaie de comparer des processeurs alors qu'ils sont dans des machines d'architectures différentes. Les machines ont plus ou moins de RAM (4 à 256 Go), ont des disques plus ou moins rapides (disques internes ou montages NFS)... Pour que le test soit valable (dans la mesure du possible, évidemment; je sais bien que les conditions sont très défavorables), je voudrais savoir quand mes processus ont eu besoin d'accéder aux disques, pour pouvoir éliminer ces cas-là (et recommencer avec moins de données).
Les accès aux disques que je vois et que je voudrais détecter sont: - l'accès aux données. J'essaie de forcer la mise en cache des données, en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes mes données tiennent en cache?). - l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la quantité de données traitée.
Pourquoi ne pas utiliser les méthodes standard de profiling de programmes ?
Hum... Est-ce que ces méthodes ne sont pas faire pour évaluer un programme, et non la façon dont une machine le fait tourner?
Dans mon cas, j'utilise des applications de calcul déjà écrites et figées, et je voudrais évaluer les différences de comportement sur différents processeurs, en éliminant le plus possible les autres facteurs. Je sais bien que certains facteurs ne pourront être éliminés, comme le temps d'accès à la mémoire. Mais peut-être y a-t-il un moyen d'évaluer ces influences? Je regarderai de plus près les « text/data/kernel page fault sleep time », pour voir si ça semble correspondre.
Je suis preneur de toute suggestion. Je mène ces tests en tant que simple utilisateur, et j'avoue être assez démuni... :(
- text/data/kernel page fault sleep time,
le temps d'attente
[...]
Merci pour ces précieuses informations!
Exemple de faute mineure : un malloc() et lors du premier accès à la
zone de mémoire données, la page est allouée en mémoire physique et
initialisée à zéro => faute mineure de page
Donc tous les processus devraient avoir une valeur non-nulle ici... Je
ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.
En fait, je cherche mieux savoir ce que fait un processus
Dans quel but ?
J'essaie de comparer des processeurs alors qu'ils sont dans des machines
d'architectures différentes. Les machines ont plus ou moins de RAM (4 à
256 Go), ont des disques plus ou moins rapides (disques internes ou
montages NFS)...
Pour que le test soit valable (dans la mesure du possible, évidemment;
je sais bien que les conditions sont très défavorables), je voudrais
savoir quand mes processus ont eu besoin d'accéder aux disques, pour
pouvoir éliminer ces cas-là (et recommencer avec moins de données).
Les accès aux disques que je vois et que je voudrais détecter sont:
- l'accès aux données. J'essaie de forcer la mise en cache des données,
en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais
pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes
mes données tiennent en cache?).
- l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la
quantité de données traitée.
Pourquoi ne pas utiliser les méthodes standard de profiling de
programmes ?
Hum... Est-ce que ces méthodes ne sont pas faire pour évaluer un
programme, et non la façon dont une machine le fait tourner?
Dans mon cas, j'utilise des applications de calcul déjà écrites et
figées, et je voudrais évaluer les différences de comportement sur
différents processeurs, en éliminant le plus possible les autres facteurs.
Je sais bien que certains facteurs ne pourront être éliminés, comme le
temps d'accès à la mémoire. Mais peut-être y a-t-il un moyen d'évaluer ces
influences?
Je regarderai de plus près les « text/data/kernel page fault sleep
time », pour voir si ça semble correspondre.
Je suis preneur de toute suggestion. Je mène ces tests en tant que
simple utilisateur, et j'avoue être assez démuni... :(
- text/data/kernel page fault sleep time, le temps d'attente
[...]
Merci pour ces précieuses informations!
Exemple de faute mineure : un malloc() et lors du premier accès à la zone de mémoire données, la page est allouée en mémoire physique et initialisée à zéro => faute mineure de page
Donc tous les processus devraient avoir une valeur non-nulle ici... Je ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.
En fait, je cherche mieux savoir ce que fait un processus Dans quel but ?
J'essaie de comparer des processeurs alors qu'ils sont dans des machines d'architectures différentes. Les machines ont plus ou moins de RAM (4 à 256 Go), ont des disques plus ou moins rapides (disques internes ou montages NFS)... Pour que le test soit valable (dans la mesure du possible, évidemment; je sais bien que les conditions sont très défavorables), je voudrais savoir quand mes processus ont eu besoin d'accéder aux disques, pour pouvoir éliminer ces cas-là (et recommencer avec moins de données).
Les accès aux disques que je vois et que je voudrais détecter sont: - l'accès aux données. J'essaie de forcer la mise en cache des données, en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes mes données tiennent en cache?). - l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la quantité de données traitée.
Pourquoi ne pas utiliser les méthodes standard de profiling de programmes ?
Hum... Est-ce que ces méthodes ne sont pas faire pour évaluer un programme, et non la façon dont une machine le fait tourner?
Dans mon cas, j'utilise des applications de calcul déjà écrites et figées, et je voudrais évaluer les différences de comportement sur différents processeurs, en éliminant le plus possible les autres facteurs. Je sais bien que certains facteurs ne pourront être éliminés, comme le temps d'accès à la mémoire. Mais peut-être y a-t-il un moyen d'évaluer ces influences? Je regarderai de plus près les « text/data/kernel page fault sleep time », pour voir si ça semble correspondre.
Je suis preneur de toute suggestion. Je mène ces tests en tant que simple utilisateur, et j'avoue être assez démuni... :(
-- Jérémy JUST
DINH Viêt Hoà
Exemple de faute mineure : un malloc() et lors du premier accès à la zone de mémoire données, la page est allouée en mémoire physique et initialisée à zéro => faute mineure de page
Donc tous les processus devraient avoir une valeur non-nulle ici... Je ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.
Après, savoir si ses compteurs sont encore utilisés ... ou s'ils sont restés là à titre historique ...
Il existe vmstat sous solaris pour avoir ces compteurs de façon globale. Si seul ton programme tourne sur la machine, tu peux considérer que la valeur de ces compteurs seront proche de la valeur que tu recherches.
J'essaie de comparer des processeurs alors qu'ils sont dans des machines d'architectures différentes. Les machines ont plus ou moins de RAM (4 à 256 Go), ont des disques plus ou moins rapides (disques internes ou montages NFS)... Pour que le test soit valable (dans la mesure du possible, évidemment; je sais bien que les conditions sont très défavorables), je voudrais savoir quand mes processus ont eu besoin d'accéder aux disques, pour pouvoir éliminer ces cas-là (et recommencer avec moins de données).
Les accès aux disques que je vois et que je voudrais détecter sont: - l'accès aux données. J'essaie de forcer la mise en cache des données, en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes mes données tiennent en cache?). - l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la quantité de données traitée.
S'il s'agit de vérifier si un programme a swappé, ne suffit-il pas de lire la valeur affichée par vmstat ?
-- DINH V. Hoa,
"écrire 'dsl' au lieu de 'désolé', c'est pas un problème d'orthographe, c'est un problème de capillarité palmaire" -- ed
Exemple de faute mineure : un malloc() et lors du premier accès à la
zone de mémoire données, la page est allouée en mémoire physique et
initialisée à zéro => faute mineure de page
Donc tous les processus devraient avoir une valeur non-nulle ici... Je
ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.
Après, savoir si ses compteurs sont encore utilisés ... ou s'ils sont
restés là à titre historique ...
Il existe vmstat sous solaris pour avoir ces compteurs de façon globale.
Si seul ton programme tourne sur la machine, tu peux considérer que la
valeur de ces compteurs seront proche de la valeur que tu recherches.
J'essaie de comparer des processeurs alors qu'ils sont dans des machines
d'architectures différentes. Les machines ont plus ou moins de RAM (4 à
256 Go), ont des disques plus ou moins rapides (disques internes ou
montages NFS)...
Pour que le test soit valable (dans la mesure du possible, évidemment;
je sais bien que les conditions sont très défavorables), je voudrais
savoir quand mes processus ont eu besoin d'accéder aux disques, pour
pouvoir éliminer ces cas-là (et recommencer avec moins de données).
Les accès aux disques que je vois et que je voudrais détecter sont:
- l'accès aux données. J'essaie de forcer la mise en cache des données,
en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais
pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes
mes données tiennent en cache?).
- l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la
quantité de données traitée.
S'il s'agit de vérifier si un programme a swappé, ne suffit-il pas de
lire la valeur affichée par vmstat ?
--
DINH V. Hoa,
"écrire 'dsl' au lieu de 'désolé', c'est pas un problème d'orthographe,
c'est un problème de capillarité palmaire" -- ed
Exemple de faute mineure : un malloc() et lors du premier accès à la zone de mémoire données, la page est allouée en mémoire physique et initialisée à zéro => faute mineure de page
Donc tous les processus devraient avoir une valeur non-nulle ici... Je ne suis pas sûr que ça corresponde à ce que j'ai constaté. Je vérifierai.
Après, savoir si ses compteurs sont encore utilisés ... ou s'ils sont restés là à titre historique ...
Il existe vmstat sous solaris pour avoir ces compteurs de façon globale. Si seul ton programme tourne sur la machine, tu peux considérer que la valeur de ces compteurs seront proche de la valeur que tu recherches.
J'essaie de comparer des processeurs alors qu'ils sont dans des machines d'architectures différentes. Les machines ont plus ou moins de RAM (4 à 256 Go), ont des disques plus ou moins rapides (disques internes ou montages NFS)... Pour que le test soit valable (dans la mesure du possible, évidemment; je sais bien que les conditions sont très défavorables), je voudrais savoir quand mes processus ont eu besoin d'accéder aux disques, pour pouvoir éliminer ces cas-là (et recommencer avec moins de données).
Les accès aux disques que je vois et que je voudrais détecter sont: - l'accès aux données. J'essaie de forcer la mise en cache des données, en exécutant plusieurs fois d'affilée chaque programme; mais je voudrais pouvoir m'assurer de l'efficacité de cette manoeuvre (est-ce que toutes mes données tiennent en cache?). - l'accès au swap. Je voudrais éviter de swapper, quitte à réduire la quantité de données traitée.
S'il s'agit de vérifier si un programme a swappé, ne suffit-il pas de lire la valeur affichée par vmstat ?
-- DINH V. Hoa,
"écrire 'dsl' au lieu de 'désolé', c'est pas un problème d'orthographe, c'est un problème de capillarité palmaire" -- ed
