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

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

En faite, je dois lancer mon bout de programme toutes les 500µs (via une IRQ) afin d’exécuter un step de la machine sur laquelle je travaille. le temps d’exécution de ce step ne doit pas dépasser les 250µs (valeur limite que l'on s'est fixé).

Actuellement mon bout de programme met entre 70µs(normal) et 140µs(lorsqu'il est préempté).

Vous allez me dire il y a encore de la marge jusqu’à 250µs. Oui c'est vrai, mais si un jour une tache prend un peu plus de temps (pour X raisons), nous serons au delà de notre limite et nuira au bon fonctionnement de notre machine (pas possible).

C'est pour ça que je cherche à rendre mon module le moins préemptée possible, il faut que je lui donne une priorité la plus importante possible.

il doit bien existé une solution a mon problème ??

**souviron34** · 07/10/2013, 16h39

Envoyé par grim7reaper

Il me semble que ce genre de chose n’est pas dispo’ quand on fait du code kernel.
Le C kernel c’est du C freestanding, pas hosted.

On peut faire un driver sans pour autant toucher au Kernel..

Envoyé par cartman_94

C'est pour ça que je cherche à rendre mon module le moins préemptée possible, il faut que je lui donne une priorité la plus importante possible.

il doit bien existé une solution a mon problème ??

D'abord, je serai toi, je remetrai le Kernel en normal, en enlevant toutes les modifs que tu lui as mises.
Ensuite, il faut optimiser le code... Pour ça, on peut peut-être t'aider si tu nous fournis un exemple. Un point de départ est de le profiler, et de voir là où il passe le plus de temps. Mais d'autres choses se voet aussi au premier coup d'oeil pour des gens habitués. MAis pour ton problème c'est d'abord et avant tout le point central.
Secondo, tu as la commande "nice".... Tu peux si tu veux lui donner la priorité des autres processus Kernel.
Tertio, si tout ça ne convient pas finalement, qu'il reste encore des "glitchs", tu peux éventuellement alors penser à modifier des trucs dans le Kernel.

Le poblème de modifier des trucs dans le Kernel, c'est que, outre le fait que c'est difficilement portable sur un autre "flavour", voire le même dans une différente version, c'est aussi hautement dangereux, entre failles et possibilités d'interrompre/empêcher des processus absolument nécessaires au sytème ("disk full" par exemple)

**mith06** · 07/10/2013, 17h53

En faite, je dois lancer mon bout de programme toutes les 500µs (via une IRQ) afin d’exécuter un step de la machine sur laquelle je travaille. le temps d’exécution de ce step ne doit pas dépasser les 250µs (valeur limite que l'on s'est fixé).

Actuellement mon bout de programme met entre 70µs(normal) et 140µs(lorsqu'il est préempté).

Vu les contraintes ça va être dur sans un noyau temps réel...

**cartman_94** · 08/10/2013, 09h42

@Souviron34 : J'ai mis le code de mon module en 1ere page. la commande "nice" ne marche que pour les processus et non les modules.

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
#include <linux/interrupt.h>
#include <linux/module.h>
#include <linux/gpio.h>
#include <linux/mutex.h>
#include <linux/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;
 
		}
 
	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");

@mith06 : Oui je sais que le mieux serait d'avoir un linux RT, mais je ne peux pas car freescale a patché linux dans tous les sens et le patch preemp_rt ne peux être installé.

**gangsoleil** · 08/10/2013, 10h20

Bonjour,

Pour moi, ton handler fait beaucoup trop de choses. Normalement, un handler doit en faire le moins possible, comme par exemple changer la valeur d'une variable pour sortir d'une boucle, ou quelque chose comme ca.

Ici, je ne vois pas l'interet d'avoir tout ce code dans le handler :

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
 
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;
 
		}
 
	gpio_set_value(GPIO_OUT, 0);
 
	return IRQ_HANDLED;
}

**souviron34** · 08/10/2013, 10h42

Et en plus, puisque là on est dans la performance, juste dans le code indiqué par gangsoleil (aujourd'hui pas le temps de regarder le reste) il y a une optimisation pas triste et toute simple :

Code C :

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

1
2
3
4
5
6
 for(i=1;i<TAILLE;i++)
		{
 
		tab[i] = tab[i-1] * i;
 
		}

se transforme en :

Code C :

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

1
2
3
4
5
6
pt0 = tab ;
pt = pt0 + 1 ;
for(i=1;i<TAILLE;i++ ) {
                *pt = i * (*pt0) : 
		pt++; pt0++ ;
		}

On économise 2 multiplications à chaque tour de boucle....

**mith06** · 08/10/2013, 11h18

D’après ce que je vois dans dans ton handler d'interruption, tu essaies salement de faire du PWM (2 Khz duty [0.0 .. 0.5]) sur ton GPIO.

Regarde plutot si il n'y a pas un contrôleur PWM dispo sur ton processeur.

Ou alors regarde du cotes des thread et de nanosleep.

**cartman_94** · 08/10/2013, 12h05

@Souviron34 : j'ai testé avec la modification que tu suggére il me faut 200µs pour effectué le calcul (contre 70µs avec le code que j'ai fais moi)

@mith06 : j'ai déjà testé avec un contrôleur PWM et j'obtiens le même résultat que la. en faite j'ai commencé par une PWM mais j'ai eu un problème de préemption donc j'en suis venu a l'interruption EPIT (interruption activable dans le processur IMX6)

@gangsoleil : Oups, je pensé que l'on pouvais y faire n'importe quoi.

En faite je dois savoir combien de temps mets le processeur pour exécuter un bout de code (j'ai pris une factorielle car je ne savais pas trop quoi faire comme code, mais si vous en avez un autre afin de tester ces performances je suis preneur).

**mith06** · 08/10/2013, 12h39

Dans un contrôleur PWM du rentre la période de découpage dans un registre, la valeur du seuil dans un autres registre. La hardware se débrouille ensuite tout seul.

Comment tu as fait pour avoir un problème de préemption?

**cartman_94** · 08/10/2013, 13h20

Pour la PWM c'est une fonction de mon processeur que j'ai activé en rentrant une période et un duty cycle (la j'ai un signal parfait). je le défini comme IRQ par request_irq et après je lui dis de faire dans mon bout de code (dans mon handler) a chaque front montant. Un peu comme le module que je vous mis en copie.

**mith06** · 08/10/2013, 14h00

J'ai pas bien compris tu veux veux changer le rapport cyclique d'un signal PWM (2Khz) à chaque période, cad toutes les 500 us? ou-bien tu veux changer son rapport cyclique sur une interruption externe (front montant d'une IO)?

Dans tous les cas si tu as du Hardware pour faire du PWM et que tu veux faire du PWM, utilise le Hard pas le Soft!

**cartman_94** · 08/10/2013, 14h17

Désolé si je me suis mal exprimé.Mais quand j'ai acheté la carte, l'option PWM du processeur n'était pas acitvé, je l'ai activé dans les sources de ma distrib (celle de la carte) et j'ai créé un module pour généré un signal de 2khz. Dans un autre module j'ai déclaré cette PWM en tant que IRQ (via request_irq). C'est dans ce dernier que je lui demande de faire mon bout de code avec le calcul factoriel (handler).

Quand j'observe sur un oscillo le temps mis pour faire ce calcul, je remarque que mon temps de calcul double de temps en temps. (d'ou ma préemption !!)

Voila j'espére avoir été plus précis sur ma démarche PWM.

**souviron34** · 08/10/2013, 14h23

Envoyé par cartman_94

@Souviron34 : j'ai testé avec la modification que tu suggére il me faut 200µs pour effectué le calcul (contre 70µs avec le code que j'ai fais moi)

ça ça veut dire que tu as un bug ailleurs...

dan ta mesure de temps ou autre chose...

tab[i] => calculé comme adresse de tab + i * sizeof(elt)
tab[i-1] => calculé comme adresse de tab + (i-1) * sizeof(elt)

comme tu n'as pas mis d'optimisation, ça m'étonnerait que ça soit calculé autrement que ça...

Donc pour chcun tu as 1 addition et 1 multiplication, pour le second tu as une addition de plus... Au total tu as 3 additions et 2 multiplications....

Dans mon code tu as seulement 2 additions...

Envoyé par cartman_94

En faite je dois savoir combien de temps mets le processeur pour exécuter un bout de code (j'ai pris une factorielle car je ne savais pas trop quoi faire comme code, mais si vous en avez un autre afin de tester ces performances je suis preneur).

Ben voyons.. Tu nous laissees réfléchir sur un pbe sans même nous l'avoir défini, en nous envoyant sur de fausses pistes....Et toi aussi....

Je ré-itère.. AVANT de voulor toucher quoi que ce soit au Kernel ou autre chose, IL FAUT SAVOIR CE QUE TU VAS FAIRE.......

Par hasard, comment mesures-tu ton temps mis ???

**cartman_94** · 08/10/2013, 14h33

Pour mesurer le temps mis par le processeur :

je met une IO à 1
je fais un calcul (ici une factorielle)
je met mon IO à 0

le temps mis par l'IO pour passer de 1 à 0 représente le temps mis pour le calcul par le processeur.

Je visualise mon IO sur un oscillo.

**souviron34** · 08/10/2013, 14h43

Et si tu enlèves tout le code du handler, ça met combien de temps ?
et quelle est l'erreur de ton oscillo ?

**cartman_94** · 08/10/2013, 14h51

Si je laisse que IO à 1 puis à 0 je met 665ns.
Pour l'erreur de mon oscillo bonne question, ça je ne sais pas, je vais voir avec un autre oscillo plus haut de gamme voir si il y a une amélioration.

Et même qu'avec le mise à 1 puis 0 de mon IO j'arrive a être préempté (je met 1.08µs)

**souviron34** · 08/10/2013, 14h54

mais de toutes façons, la question la plus importante est :

quel code veux-tu réellement mette dans le handler ?????

Là tu nous parles de préemptation, e modifer le Kernel, et autres, mais on s'en fout royalement, suivant ce que tu veux faire.....

Faut prendre les choses dans le bon ordre, et pas à l'envers...

**cartman_94** · 08/10/2013, 15h07

dans mon handler il faudrait que je mette le firmware de la machine sur laquelle je travaille pour vraiment simuler son temps de calcul. Mais pour ça il faut retravailler le code du firmware en y mettant les bonnes adresses mémoires, redéfinir les I/O .... tous un bordel.
Le code du firmware est "simple" c'est juste des "if" et des affectations de variable (donc pas calculs).

Il faudrait trouver un code similaire afin que je puisse le tester et voir les perfs du processeur.

Après étant un débutant au niveau Kernel (et pas un As en C non plus), j'ai fais quelque chose de simple mais avec une boucle assez longue pour faire varier son temps de calcul.

**mith06** · 08/10/2013, 15h20

Désolé j'ai toujours pas compris ce que tu veux faire.....
Es-tu toi même sure d'avoir compris?

**cartman_94** · 08/10/2013, 15h38

Oui oui j'ai compris ce que je veux faire.

Pour faire simple il faut que toutes les 500µs je soit capable d'exécuter un bout de code (un step de la machine) et que le temps mis par ce step ne dépasse pas les 250µs.

Actuellement (sur la machine) nous avons une carte avec une pwm qui se comporte comme une IRQ qui se déclenche toutes les 500µs et un step de la machine est alors exécuté. (carte devenu obsolète)

Nous avons acheté une nouvelle carte pour remplacer l'ancienne. Mon boulot est de généré un signal de 500µs (avec une pwm ou autre) et sur chaque front montant de cette pwm d'exécuter un step de la machine (la même chose qu'avec l'ancienne carte). je dois voir si cette nouvelle carte conviens a nos besoin.

Je dois la tester dans son temps d'exécution pour voir si elle respecte bien le temps max d'un step (d'ou mon pb de préemtion)

Je peux pas être plus clair sur ce que je dois faire.

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

C

Discussions similaires

Partager

Partager