Est-il possible d'affecter une priorité à un module ?

**cartman_94** · 02/10/2013, 17h12

Bonjour

Je développe sur une carte Dimm mx6, avec un processeur ARM Cortex A9 (de chez Freescale).

Dans un module, je génère une IRQ toutes les 500µs, et toutes ces 500µs j’exécute un bout de code (pour faire mes test je fais un calcul factorielle pour mesurer son temps d’exécution).

C'est la que j'ai un problème, mon temps d'exécution double de temps en temps (une fois sur deux lorsque je lance mon module), on m'a dit que mon calcul est préempté. J'ai essayé d'appliquer un patch PREEMPT_RT au linux (3.0.35) mais il est patché par Freescale et le fournisseur de la carte donc impossible de le rendre RT. (trop de modifications subies)

J'ai décidé de "nettoyer" Linux en enlevant toutes les fonctionnalités dont je ne me servirai jamais (usb, touchscreen ....) j'ai gagné en rapidité de temps d'exécution (28µs au lieu de 70µs auparavant) mais mon calcul est toujours préempté (1 fois sur 8 lorsque je lance mon module, y a du mieux mais c'est pas encore ça).

Je voulais savoir si il existe une commande afin de rendre prioritaire mon module pour empêcher qu'il se fasse préempter ?

Si vous connaissez un autre moyen/méthode pour éviter d'être préempté je suis a votre écoute.

Merci d'avance

**Metalman** · 02/10/2013, 17h58

Un linux classique ne sera jamais "non préemptable".
C'est la base des OS "modernes" ET classiques.

Je ne connaissais pas trop "PREEMPT_RT", mais en lisant ça je vois que c'est le patch officiel.
Tant que tu n'auras pas le patch dédié pour faire du temps réel, c'est foutu.
Essaye de voir avec Freescale s'ils n'ont pas un Linux RT à leur sauce.

Ce qui m'inquiète c'est qu'ils emploient : "Ce patch a pour effet de donner au noyau Linux un comportement temps réel dur"
avec :
"Il agit en rendant préemptible la majeure partie du code du noyau, et en particulier les sections critiques, les gestionnaires d'interruptions."
Bref... ça devient juste ultra-ultra préemptible partout... du coup tout le monde a la main quand il veut ! (si on résume à l'arrache, hein !

)

**cartman_94** · 03/10/2013, 09h16

J'ai déjà demandé a Freescale, il n'ont pas de patch pour le rendre RT.

Mais ma question était de savoir si on pouvais rendre un module prioritaire afin de ne pas être interrompu. (un peu comme la commande "chrt" pour les processus)

Sinon on m'a dis d'utiliser les sémaphores/mutex avec jetons pour voir si mon problème persiste toujours. A votre avis est-ce une bonne solution ??

**Metalman** · 04/10/2013, 10h26

Les sémaphores/mutex sont "à priori" des syscalls ou en utilisent... donc ça préemptera dessus à coup sûr.

S'il n'y a aucun patch "temps réel", alors il y aura *toujours* de la préemption plus ou moins prévisible (tu peux être quasiment sûr qu'un appel système fera de la préemption déjà... donc moins tu en mettras, moins ton processus sera coupé).

**cartman_94** · 04/10/2013, 10h53

J'ai trouvé un site qui explique comment rendre son linux RT avec le patch preempt_rt mais il faut faire des modification de la mort et vu mon niveau je ne préfere pas essayer.

On m'a dis qu'il existé un pragma pour éviter la préemption des modules.

1- Déjà c'est quoi un pragma ?
2- Quel pragma choisir ?

**Metalman** · 04/10/2013, 12h28

Alors une pragma... c'est... le "code" pour le précompilateur (cpp dans la suite gcc).
Parfois on les appelles les "pragma comments".

Par exemple, tout ça ce sont des pragmas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
#ifndef MON_HEADER_H_
# define MON_HEADER_H_ 42
 
# include <unistd.h>
# include "monfichier.h"
 
#endif /* !MON_HEADER_H_ */

Je ne suis pas un expert en précompilation ni en pragma, mais ça permet déjà de désactiver des bouts de code en fonction de l'architecture cible (par exemple si ma Debian x86 ne connait pas une fonction ou un define, mais que mon Solaris SPARC oui, mais mon NetBSD Alpha n'a pas la bonne valeur... on va ajouter/supprimer/modifier le code source qui sera compilé, grâce au précompilateur) donc d'ajouter de la portabilité....

Et ça permet "aussi" d'ajouter/supprimer des bouts de code si tu le souhaites (par exemple retirer le support du protocole X.25 dans ton kernel, en commentant un "define" qui permet d'activer/désactiver le "ifndef" autour du driver... parce que tu n'as rien qui utilise du X.25 sur ta machine)

Dans ton cas, ça permet de modifier le comportement du kernel, comme l'exemple du driver.

Je ne connais pas assez les patchs RT pour te dire laquelle utiliser. Désolé :s

**cartman_94** · 04/10/2013, 12h48

Merci de ton explication sur les pragmas

Je n'utilise pas de patch RT (impossible a faire fonctionner dans mon cas) d'ou mon problème de préemption. je souhaite juste que mon module ne soit pas préempté par une autre tâche lorsque je le lance.

J'ai regardé les #pragma qui existe sur le net (y en a un paquet) et je ne sais pas lequel utiliser.

**Médinoc** · 04/10/2013, 13h18

↑↑Attends, toutes les directives de compilation sont appelées des pragmas maintenant?

Pas seulement les différents #pragma, qui sont spécifiques aux compilateur(s) qui les supporte(nt) ?

**cartman_94** · 04/10/2013, 14h11

Médinoc, je vois que tu as l'air de t'y connaître en #pragma.

Saurais-tu m'aider à résoudre mon problème ?

**Metalman** · 04/10/2013, 15h31

J'ai dû me gourer....

Médinoc aura sûrement une meilleure explication que la mienne sur les autres possibilités des pragmas en C.

Mais comme ça concernait un module kernel... de ce que j'ai vu dans les sources des kernels Linux et FreeBSD... c'est surtout des #define #ifndef #endif !
Et hormis un #pragma once (similaire à la combinaison #ifndef #define #endif )... je ne vois pas trop ce qu'il peut y avoir d'autre dans ton cas... (sachant que #pragma once c'est le seul que j'ai dû utiliser dans le passé...)

**Médinoc** · 04/10/2013, 16h33

Malheureusement je n'ai jamais fait de programmation noyau, encore moins de programmation RT, donc aucune idée si certains pragmas (supportés par quel compilateur? GCC?) s'y appliquent.

Les seuls pragmas dont je me souvienne sont les classiques (#pragma once), ceux de Visual (#pragma message, #pragma warning) et ceux liés à OpenMP, la bibliothèque de multithreading nécessitant un support du compilateur (justement pour ses pragmas, #pragma omp blabla).

**grim7reaper** · 04/10/2013, 19h25

Salut,

Envoyé par cartman_94

Je voulais savoir si il existe une commande afin de rendre prioritaire mon module pour empêcher qu'il se fasse préempter ?

Il y a probablement moyen de faire quelque chose en mettant le code que tu veux exécuter sans interruption entre un appel à preempt_disable et preempt_enable.
Je ne suis pas certain que ça soit la meilleure solution, mais à priori ça peut se tenter.
Ou il vaut peut-être mieux passer par un spinlock (ça dépend de ton cas), car ça désactive aussi la préemption.
Dans tout les cas, je te conseille un peu de lecture sur le sujet : Linux Device Drivers, Third Edition, chapitre 5.

Envoyé par cartman_94

On m'a dis qu'il existé un pragma pour éviter la préemption des modules.

1- Déjà c'est quoi un pragma ?
2- Quel pragma choisir ?

Je n’ai jamais entendu parler d’une pragma de ce genre (mais je suis peut-être passé à côté, et tout cas ça sera plutôt étonnant qu’une pragma puisse y faire quelque chose), il y a peut-être eu un abus de langage.
Le meilleur moyen de le savoir et de demander à la personne qui t’a parlé de cette fameuse pragma

**cartman_94** · 07/10/2013, 09h36

Salut,

On m'a aussi conseillé d'utiliser un spinlock pour désactiver la préemption, j'ai essayer sans grande réussite (je n'ai certainement pas dû le faire correctement).

J'y connais pas grand chose en programmation de spinlock (juste entend parler en cours de TR, mais jamais utilisé) et c'est assez important pour moi de ne plus avoir ce problème de préemption.

Pouvez m'aider implémenter les spinlock à mon module ??

code du module :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
#include <linux/interrupt.h>
#include <linux/module.h>
#include <linux/gpio.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
#include <linux/spinlock_types.h>
 
#include <asm/spinlock.h>
 
#define MXC_INT_EPIT1 88
 
#define TAILLE 10000
 
// Sortie sur GPIO_0 
#define GPIO_OUT 32
 
 
 
	//Handler 
static irqreturn_t gpio_handler(int irq, void * ident)
{
	int i;	
	static int tab[TAILLE];
 
	i=0;
 
	gpio_set_value(GPIO_OUT, 1);
	tab[0] = 1;
 
	for(i=1;i<TAILLE;i++)
		{
		tab[i] = tab[i-1] * i;
		//tab[i] = i;
		}
 
   gpio_set_value(GPIO_OUT, 0);
 
	  return IRQ_HANDLED;
}
 
	//Module Init
static int __init gpio_init (void)
{
  int err;
	//allocation memoire pour le GPIO_OUT
  if ((err = gpio_request(GPIO_OUT, THIS_MODULE->name)) != 0)
    return err;
 
	//direction GPIO_OUT : Output
  if ((err = gpio_direction_output(GPIO_OUT,1)) != 0) 
  {
    gpio_free(GPIO_OUT);
    return err;
  }
 
  if ((err = request_irq(MXC_INT_EPIT1, gpio_handler, IRQF_SHARED, THIS_MODULE->name, THIS_MODULE->name)) != 0) 
  {
    gpio_free(GPIO_OUT);
    return err;
  }
 
 
  return 0; 
}
 
	//Module Exit
static void __exit gpio_exit (void)
{
  free_irq(MXC_INT_EPIT1, THIS_MODULE->name);	
  gpio_free(GPIO_OUT);	//On libere la GPIO_OUT
}
 
module_init(gpio_init);
module_exit(gpio_exit);
MODULE_LICENSE("GPL");

**ManusDei** · 07/10/2013, 12h56

Si tu n'as pas d'autre idée, regarde la doc du processeur ou de la carte.
Tu peux désactiver les interruptions, puis les réactiver, ce qui permet d'éviter toute préemption.

C'est en général pas compliqué, il suffit d'écrire quelques bits à 1 (ou à 0) à l'adresse utilisée pour les IT pour bloquer la prise en compte d'IT, puis de remettre à 0 (ou à 1) à la fin de la procédure.

Ça se fait très bien en C (c'est juste écrire une valeur à une adresse).

Le gros problème est de se farcir la doc pour trouver l'adresse, qui est différente pour chaque carte, et de faire attention au moment où on fait les écritures.

**souviron34** · 07/10/2013, 14h07

Envoyé par cartman_94

Dans un module, je génère une IRQ toutes les 500µs, et toutes ces 500µs j’exécute un bout de code (pour faire mes test je fais un calcul factorielle pour mesurer son temps d’exécution).

C'est la que j'ai un problème, mon temps d'exécution double de temps en temps (une fois sur deux lorsque je lance mon module), on m'a dit que mon calcul est préempté. J'ai essayé d'appliquer un patch PREEMPT_RT au linux (3.0.35) mais il est patché par Freescale et le fournisseur de la carte donc impossible de le rendre RT. (trop de modifications subies)

Comment ton "module" est-il lancé ?
Qu'est-ce que c'est que ton "module" ?

Est-ce qu'une fonction appelée par un simple appel à alarm avec le flag realtime :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
       signal ( SIGALRM, (void (*)())Timer_Expiration );
       setitimer (ITIMER_REAL, &rttimer, &old_rttimer);

ne marcherait pas ???

Normalement le timer est en microsecondes...

**cartman_94** · 07/10/2013, 14h23

@souviron34 : 1) je lance le module par la commande "insmod". Le module transforme un signal (EPIT) en une interruption. J'exécute un bout de code a chaque front montant de l'interruption.
2) Après je n'ai pas essayer de le faire par l'appel d'une alarm comme tu le propose. (il me faut une interruption précise toute les 500µs)

@ManusDei : j'ai désactiver quelques interruptions (pas de la même méthode que toi, mais par la config du kernel en supprimant des options), mais je ne sais vraiment pas lesquelles je peux encore enlever. je te met la liste des interruption qu'il me reste dans cat /proc/interrupts :

CPU0 CPU1 CPU2 CPU3
34: 1 0 0 0 GIC sdma
35: 0 0 0 0 GIC VPU_JPG_IRQ
37: 0 0 0 0 GIC imx-ipuv3
38: 1 0 0 0 GIC imx-ipuv3
39: 0 0 0 0 GIC imx-ipuv3
40: 0 0 0 0 GIC imx-ipuv3
43: 1 0 0 0 GIC galcore interrupt service for 2D
44: 0 0 0 0 GIC VPU_CODEC_IRQ
59: 1823 0 0 0 GIC IMX-uart
75: 0 0 0 0 GIC usb_wakeup
81: 0 0 0 0 GIC THERMAL_ALARM_IRQ
87: 198056 0 0 0 GIC i.MX Timer Tick
88: 27965893 0 0 0 GIC epit, irq_epit
121: 0 0 0 0 GIC dvfs
139: 0 0 0 0 GIC mmdc_1
144: 0 0 0 0 GIC mmdc_1
145: 0 0 0 0 GIC mmdc_1
146: 0 0 0 0 GIC mmdc_1
150: 148952 0 0 0 GIC enet
343: 0 0 0 0 GPIO gpiolib
431: 0 0 0 0 GPIO gpiolib
IPI0: 0 26578 831 81 Timer broadcast interrupts
IPI1: 1273 10358 438 228 Rescheduling interrupts
IPI2: 2 4 6 6 Function call interrupts
IPI3: 2158 2068 4225 4226 Single function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
LOC: 1749 125 65 43 Local timer interrupts

**souviron34** · 07/10/2013, 15h03

Envoyé par cartman_94

2) Après je n'ai pas essayer de le faire par l'appel d'une alarm comme tu le propose. (il me faut une interruption précise toute les 500µs)

C'est bien ce qu'est censé faire la fonction alarm avec un timer itmerreal....

**cartman_94** · 07/10/2013, 15h32

la fonction "alarm" avec un itimer_real m'évitera d'être préempté ?

**gangsoleil** · 07/10/2013, 16h00

En fait, il y a un probleme conceptuel a rendre un module non preemptable : tu prends un risque de famine sur ton OS.

Ton module se lance toutes les 500 ms, et dure 100ms, ce qui laisse 400ms au systeme pour faire autre chose. Que se passera-t-il si, quelle que soit la raison, ton module prend plus de 500 ms ? Ou bien si le systeme a besoin de plus de 400ms ?