Discussion :

[dodo285]

Bonjour a tous,

Juste une petite question concernant l'appel posix mmap dont voici le prototype:

Code :

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

1
2
 
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);

Que se passe t'il lorsque le second argument length est plus grand que le fichier pointé par le descripteur fd fournis en 5ème argument.

Merci d'avance pour votre aide.

[fearyourself]

La page man ne dit rien là-dessus on dirait. Tente et revient nous le dire?

[sambia39]

Bonsoir,

Il ne peut y avoir que deux réponses (points). Mais avant toute chose il faut savoir que sur certains systèmes d’exploitation la taille de projection mémoire de la fonction "mmap" est limitée. Ainsi donc sur ces systèmes la taille de projection est fixée, toute comme le nombre maximal de projections mémoire (65535 soit environ la taille d’un entier 65735 et la capacité de projection est limitée le plus souvent à 1024).

Première points : la fonction "mmap" fonctionne correctement parce que la longueur de projection est acceptable, c'est-à-dire capable de projeter la totalité du fichier en mémoire (il faut également retenir que mmap procède toujours à une projection mémoire par excès c'est-à-dire la taille de bloc mémoire capable de contenir un certain nombre d'entier de pages mémoire)

Deuxième points: la fonction "mmap" échoue parce:
->La longueur de projection total est dépassée. En clair une demande de projection mémoire beaucoup trop grande ou que le nombre de projections mémoire total est dépassée , le noyau devient instable tout simplement parce qu'il ne peut pas mettre à jour l’ensemble de ses données internes.
->La projection est effectuée sur une adresse invalide.
->Une mauvaise utilisation des flags (attributs) adéquats
->L'utilisation d'une mémoire anonyme (projection mémoire anonyme) interdit sur certain système d’exploitation, car celle-ci demande à faire obligatoirement une copie dans une page virtuelle nouvelle (Attention sur certain système d'exploitation, ce mécanisme est utilisé comme mémoire partagé mais uniquement lorsque le système d'exploitation vous autorise l'utilisation de la projection anonyme) ou peut être parce que; une où des adresses sollicitées ne sont pas alignées.

Il est donc toujours conseil de connaître les raisons exactes de l'échec de "mmap" afin de prendre des mesures nécessaires, mais aussi sollicitées une projection mémoire raisonnable pour éviter des désagréments.

Au final pour résumer et apporter une réponse; Si la longueur de projection dépasse les limités autoriser ou tout simplement dépasse la taille de la mémoire totale (mémoire physique et swap) mmap échoue.

à bientôt

[dodo285]

Merci pour cette réponse, il semble donc qu'il soit possible de projeter une zone plus grande que le fichier lui même.
J'ai par ailleurs essayé et, la zone qui dépasse celle de la projection du fichier semble être remplie de NUL (la projection est en char*) en tout cas sur mon système (linux 3.16)
Par contre, il n'est pas vrais que:

Si la longueur de projection dépasse la taille de la mémoire totale (mémoire physique et swap) mmap échoue.

Et j'en suis sur car j'ai également essayé et (en tout cas sur mon linux 3.16) il est tout a fait possible d'avoir une projection plus grande que la mémoire physique.

Voilou.

[dalfab]

Par contre, il n'est pas vrais que:

Si la longueur de projection dépasse la taille de la mémoire totale (mémoire physique et swap) mmap échoue.

Et j'en suis sur car j'ai également essayé et (en tout cas sur mon linux 3.16) il est tout a fait possible d'avoir une projection plus grande que la mémoire physique.

En est-tu bien sûr?
Le mmap est forcément limité par :
* La mémoire adressable par le process (comment pourrait-on se servir d'un pointeur qui irait au dela de l'espace adressable)
* La mémoire physique + La mémoire swap (comment pourrait-on maintenir en mémoire plus que ce que le système de mémoire ne peut gérer)
* Si le mmap se fait sur un fichier physique, j'ai des doutes sur le fait que l'on puisse gérer plus qu'une taille max de fichier, car au moment de la sauvegarde, que va-t-il se passer?

Si on suppose un PC 32 bits avec 2GO de RAM + 2GO de swap. Un process 32 bits ne peut adresser que 3GO. Un mmap ne pourra en aucun cas fonctionner à plus de 3GO.

[picodev]

Sans doute Dodo285 a-t-il oublié le swap ...
Mais un programme 64 bits sur une plateforme 64bits classique avec 4Go de Ram et 4Go de swap pourrait très bien mmaper un fichier de 16Go puisque l'OS peut allouer suffisamment de mémoire virtuelle, mais il ne pourra sans doute pas mmaper anonymement 16Go sur /deb/null, je suppose.
Maintenant des OS comme linux ont une politique très optimiste, on peut allouer plus de mémoire que de mémoire réellement disponible quitte à passer l'OOB, et (de souvenir) il me semble que les pages vides ne sont pas réellement allouées tant qu'elles ne sont pas écrites. Mais là ce sont des particularités linux que je ne maîtrise pas bien.

[sambia39]

Bonjour,

Merci pour cette réponse, il semble donc qu'il soit possible de projeter une zone plus grande que le fichier lui même.
J'ai par ailleurs essayé et, la zone qui dépasse celle de la projection du fichier semble être remplie de NUL (la projection est en char*) en tout cas sur mon système (linux 3.16)
Par contre, il n'est pas vrais que:



Et j'en suis sur car j'ai également essayé et (en tout cas sur mon linux 3.16) il est tout a fait possible d'avoir une projection plus grande que la mémoire physique.

Voilou.

J'ai des doutes sur ce dont vous me faite part;
à ce que je sais et j'en suis sur, c'est qu'il vous est théoriquement possible d’allouer X en taille mémoire à condition que cette mémoire n’excède pas la taille de la mémoire virtuelle totale ou réelle (mémoire physique et swap) sauf si vous avez d'autres arguments qui le justifient.

J'admets que les techniques d'allocations mémoire de mmap sont totalement différentes de malloc mais néanmoins tous deux ne peuvent excéder la mémoire totale dans le doute; je vous suggère une autre approche pour voir si votre système d'exploitation GNU/Linux est capable de dépasser la taille mémoire que vous sollicitez et ce en plusieurs blocs voir si possible d'un coup. (voir le code source sur cette discussion et faite nous un retour si possible )
à bientôt

[picodev]

Par curiosité j'ai fait un petit test.
Plateforme : linux 4.4 64 bits, programme compilé en mode 64 bits, GlibC 2.24, 4Go RAM + 8 Go de swap
J'ai créé un fichier de 25 Go que j'ai réussi à mmaper ... ce qui ne me semble pas étonnant, tant que ça rentre dans l'espace d'adressage. Mon CPU a 36 bits pour la mémoire physique et 48 bits pour l'adressage virtuel.

[dodo285]

Petite précision sur le test que j'ai effectué, voici le code:

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
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
 
int main(int argc, char* argv[])
{
	int fd;
	struct stat sfd;
	long size;
	long i;
	char* mm;
	char c;
	fd = open(argv[1],O_RDWR);
	fstat(fd,&sfd);
	mm = (char *)mmap(NULL, sfd.st_size, PROT_READ, MAP_PRIVATE | MAP_DENYWRITE, fd, 0);
 
	if (mm == NULL) return(1);
 
	getchar();
	for(i = 0; i < sfd.st_size + 1; i++)
	{
		c = mm[i];
	}
	printf("Terminated\n");
	return(0);
}

Ma machine est un x86_64 linux 3.16 64bits, 32Go de mémoire, 4Go de swap.

J'ai utilisé un fichier de 44Go donc plus grand que 32+4 = 36Go.

Le processus démarre a 44Go en mémoire virtuelle ce qui est normal mais le RSS est très petit (quelques Ko).
Ensuite après avoir pressé une touche, la RSS monte progressivement jusqu'a 28Go a peut près puis stagne gentiment jusqu’à retourner 0.

Le fait est que je ne modifie pas le contenu de la projection donc il n'est pas nécessaire au noyau de mapper la projection en mémoire physique, dans le cas contraire je n'ai aucune idée de se qu'il pourrait se produire.
En effet si on utilise le flag MAP_PRIVATE la projection n'est pas destinée a être réécrite sur le disque, donc toute modification dans ce cas doit être stockée en mémoire physique.

[picodev]

Ah ben oui, le mmap doit être en shared pour pouvoir utiliser sereinement l'espace disque sans avoir besoin de mémoire physique autre, sinon il va allègrement planter.