habib.bouaziz-viallet a écrit :
>On Mon, 12 Sep 2005 20:30:12 +0200
>JLM aka cityhunter <jlm_devel@???> wrote:
>
>
>
>>habib.bouaziz-viallet a écrit :
>>
>>
>>
>>>Bonsoir la liste Guilde !
>>>
>>>Je suis en train de modifier un pilote de port série synchrone sur
>>>une plateforme légère (Cf. developer.axis.com) pour qu'il s'adapte à
>>>un codec particulier (CS4334)
>>>
>>>l'objectif etant de faire ceci : ./madplay < mon_morceau.mp3 |
>>>./transfert_sser
>>>
>>>le programme "transfert_sser" ouvre le port serie synchrone
>>>(/dev/sser0), recoit le flux standard en entrée et le redirige vers
>>>/dev/sser0. Le codec est connecté en hard sur ce port série.
>>>
>>>Mon problème : C'est que *kmalloc() échoue dans mon code pilote de
>>>/dev/sser0 au bout de quelques appels (j'en suis sûr mais je ne peux
>>>pas donner de copie d'ecran vu qu'il n'y a pas d'écran ...)
>>>
>>>La question : Y a t'il des précautions avec *kmalloc() ?? ca fait
>>>déja longtemps que j'y suis et je cherche de l'aide aussi sur la
>>>liste de axis
>>>
>>>HELP !!, Habib.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>Bonjour.
>
>
>
>>The data sizes available are generally powers of two. In the 2.0
>>kernel, the available sizes were actually slightly less than a power
>>of two, due to control flags added by the management system. If you
>>keep this fact in mind, you'll use memory more efficiently. For
>>example, if you need a buffer of about 2000 bytes and run Linux 2.0,
>>you're better off asking for 2000 bytes, rather than 2048. Requesting
>>exactly a power of two is the worst possible case with any kernel
>>older than 2.1.38 -- the kernel will allocate twice as much as you
>>requested. This is why /scull/ used 4000 bytes per quantum instead of
>>4096
>> In any case, the maximum size that can be allocated by /kmalloc/ is
>> 128
>>KB -- slightly less with 2.0 kernels. If you need more than a few
>>kilobytes, however, there are better ways than /kmalloc/ to obtain
>>memory, as outlined next.
>>
>>kmalloc a aussi d'autres inconvénients il alloue des chuncks de
>>mémoires : si tu spécifie une taille trop grande il se peut que
>>l'allocation échoue si aucun chunk de mémoire n'est assez grand (si la
>>
>>mémoire est très fragmentée
>>
>>
>> get_free_page and Friends
>>
>>If a module needs to allocate big chunks of memory, it is usually
>>better to use a page-oriented technique. Requesting whole pages also
>>has other advantages, which will be introduced later, in "The mmap
>>Device Operation" in Chapter 13, "mmap and DMA".
>>
>>
>>http://www.xml.com/ldd/chapter/book/ch07.html
>>
>>
>Trés bonne réf mais je n'ai pas le bouquin. J'apprends enfin ce que veut
>dire GFP_xxx comme argument de *kmalloc() et je crois que mon problème
>vient d'ici.
>
le bouquin est en fdl (free documentation liscence.....) donc n'hésite
pas a consulter
>Je m'interroge sur mon système ; il n'y a pas par défaut sur ma
>plateforme de zone de swap (je peux en monter en FLASH mais pas
>recommendé) est ce que mon problème d'alloc ne viendrait pas d'ici ? Je
>ne suis pas un gourou de la mémoire virtuelle sous linux mais j'ai cru
>avoir lu que la mémoire du noyau n'est pas swappable ...
>
faux la mémoire kernel est swapable, bien qu'il existe des mécanismes
pour empêcher ce comportement.....
>Je vais monter une zone de swap aujourd'hui et on verra
>
>
>>dans un de mes drivers j'avais besoin de grosse tailles de mémoire
>>pour faire du DMA, j'allouais des petits chunks de pages que je
>>linkais entre eux pour faire du scatter gather (sur les périfs le
>>supportant on passe directement la liste et le dma s'éffectue au fur
>>et à mesure, remplissant les différents chunks... sur les dma ne le
>>supportant pas il existe en général deux jeux de registres un jeu dit
>>"working" et un jeu de "programation" en général on peut programmer
>>celui de programmation pendant que le working et en travail, et on
>>peut programmer automatiquement le swap entre les deux.... sur l'IT de
>>fin de dma on reprogramme celui de programmation et ainsi de
>>suite....) il faut mieux utiliser des buffers tournants plutôt que
>>d'allouer/désallouer....
>>
>>
>Trop compliqué pour moi.
>
pourtant les buffers tournants sont simples à mettre en oeuvre : tu
alloue X buffer dont tu stocke les pointeurs dans un liste chainée
circulaire, il te suffit ensuite de 2 pointeurs "next" "free", tu
stockes les buffers arrivant dans free et tu les sorts de next (et tu
fais next = next->next) tu ne déqueue plus rien si next == free et tu
suspends le procéssus appelant si free->next=next
de rien
JL
