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.
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 ...
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.
>
>
>
Merci, Habib
