RAM installée non utilisable complètement, nouvelle approche?

Tags: #<Tag:0x00007f63d28cde70>

Bonjour,

J’ai moi aussi des problèmes de différence entre la RAM installée et la RAM visible avec ma debian 12. Je précise si cela a un intérêt que pour l’installation j’ai appliqué les options acpi_osi=Linux pci=nomsi sinon l’installation ne se lancait pas.

J’ai parcouru un peu tous les messages sur le forum et ailleurs sans trouver de véritable réponse ou alors sans les comprendre (je suis loin d’être informaticien donc désolé d’avance si je suis imprécis dans les termes).

En gros, j’ai deux barrettes de 2 Go sur mon portable Asus et la commande free ne me donne que 2,9 utilisable.
Avant de chercher à changer les choses, peut-on m’expliquer où est passé ce mega ? Si c’est prévu par la distribution et qu’il est utilisé néanmoins à bon escient, cela ne vaut peut-être pas la peine de chercher à changer les choses si c’est comme cela que ca marchera le mieux (mais quand même, 1Go de RAM sur 4Go, cela peut changer le comportement de mon ordi).

Merci de m’avoir lu et merci d’avance de m’apporter votre science et vos commentaires

Donc pour mes infos :

  • portable Asus F70SL
  • processeurs : 2 × Intel® Core™2 Duo CPU T5850 @ 2.16GHz
  • processeur graphique : NV98
  • ma carte mère accepte bien en principe 4Gib
  • dans le bios et au démarrage de l’ordi il me dit bien memory installed 4096Mb
  • mon Bios est à jour de la dernière version qui est parue en 2009
  • debian en 64 bits actuellement, matériel apparament compatible, version de noyau 6.1.0-27-amd64 (64-bit), plateforme graphique : X11
  • si je fais le test depuis d’autres debian live, même en 32bit j’ai les mêmes infos sur ma RAM
  • J’ai fait les tests alternativement avec une seule barrette de 2Go, sur chacun des ports, à chaque fois la commande free me renvoie 1,9Go de mémoire totale, mais quand je mets les deux la même commande me donne 2,9Go de mémoire totale

PS : aucune donnée à sauvegarder sur cet ordinateur, je peux « prendre des risques », je compte de toute façon repartir sur une installation propre debian 12 LXQt plutôt que KDE que j’ai actuellement un peu gourmand pour ma machine qui manque de fluidité

L’option de noyau « pci=nomsi » désactive les interruptions MSI (Message Signaled Interrupts) pour les périphériques PCI, et n’influe donc pas l’allocation mémoire.
Le différentiel entre quantité de mémoire physique installée et celle disponible pour le système rapportée par la commande « free » provient de la mémoire partagée réservée à la carte graphique intégrée (IGPU), qui évolue dynamiquement en fonction du besoin, et probablerment configurable dans le BIOS.

La commande suivante devrait montrer des lignes ‹ mémoire ›:
lspci -v | awk '/3D|VGA/' RS=

1 J'aime

Bonsoir Verner,
Merci pour ta réponse.
Pour l’option de noyau je préférais juste préciser… histoire de si ça pouvait avoir son importance.
Pour ces options dans le bios justement il me semble que je n’ai rien pour configurer le comportement de la carte graphique. Faudrait que je mette des images du bios pour illustrer, mais je ne sais pas comment faire cela, je vais me renseigner.
Voici le résultat de la commande

lspci -v | awk '/3D|VGA/' RS=

01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce 9300M GS] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. U6V laptop
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at dc00 [size=128]
Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: nouveau
Kernel modules: nouveau

J’ai l’impression (aussi dans ma config) que le lspci de l’IGPU rapporte en fait uniquement la mémoire strictement minimum au système pour fonctionner.
Si je l’augmente dans le BIOS, je ne vois pas de différence rapportée par lspci.
Cette zone mémoire n’est pas facile à tracer, entre le BIOS et linux.
Pour comparer, « free -mh » permettra de voir une différence au démarrage, avant que le graphique ne soit trop sollicité.
Voir aussi ce que rapporte glxinfo fourni par mesa-utils:
glxinfo | grep -i 'device\|memory'

Mais le différentiel que tu rapportes entre 1 et 2 barrettes mémoire ne me semble pas cohérent.

Je viens de passer la commande au redémarrage de l’ordinateur. Voici le résultat de

free -mh
total utilisé libre partagé tamp/cache disponible
Mem: 2,9Gi 750Mi 1,8Gi 10Mi 541Mi 2,2Gi
Échange: 4,9Gi 0B 4,9Gi

pour

glxinfo | grep -i 'device\|memory'

j’obtiens :

Device: NV98 (0x6e9)
Video memory: 500MB
Unified memory: no
Memory info (GL_ATI_meminfo):
VBO free memory - total: 400 MB, largest block: 400 MB
VBO free aux. memory - total: 838859 MB, largest block: 838859 MB
Texture free memory - total: 400 MB, largest block: 400 MB
Texture free aux. memory - total: 838859 MB, largest block: 838859 MB
Renderbuffer free memory - total: 400 MB, largest block: 400 MB
Renderbuffer free aux. memory - total: 838859 MB, largest block: 838859 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 500 MB
Total available memory: 1049075 MB
Currently available dedicated video memory: 400 MB
GL_NVX_gpu_memory_info, GL_NV_conditional_render, GL_NV_copy_image,
GL_MESA_window_pos, GL_NVX_gpu_memory_info, GL_NV_ES1_1_compatibility,

C’est donc bien par là que ça se passe, probablement différent si 1 ou 2 barettes.

Sans compter que le pilote nouveau pour NVIDIA n’est pas très bon et ça peut influer sur la mémoire (hors carte GPU).

Donc cela veut dire que ma carte graphique se réserve lus de mémoire quand il y en a plus?
Est-ce que c’est bien que cela fonctionne ainsi ou est-ce que cela nuit au fonctionnement du portable?
Je l’utilise essentiellement pour lire de la musique en streaming et internet mais j’aimerais aussi pouvoir y lire des vidéos en streaming quand je me déplace

Mon BIOS n’a pas de réglage mémoire graphique.

Citation Sans compter que le pilote nouveau pour NVIDIA n’est pas très bon et ça peut influer sur la mémoire (hors carte GPU).

je crois que le pilote de ma carte n’existe plus dans le debian, je vais essayer de retrouver comment faire pour vérifier cela

Detected NVIDIA GPUs:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G98M [GeForce 9300M GS] [10de:06e9] (rev a1)

Checking card: NVIDIA Corporation G98M [GeForce 9300M GS] (rev a1)
Your card is only supported by the 340 legacy drivers series, which is only available up to buster.

Le pilote existe dans Debian/SID.
Pour cela:
d’abord tu fait une mise à jour de ton système:
apt update
apt upgrade
Pour etre sur qu’aucun paquet ne soit en attente.
Ensuite il te suffit d’ajouter la ligne SID dans /etc/apt-sources.list.d/nvidia-sid.list
deb http://deb.debian.org/debian/ sid main contrib non-free non-free-firmware

ensuite

    apt-update
    apt install nvidia-legacy-340xx-driver

ensuite tu commente la ligne sid dans le fichier, puis de nouveau
apt update

pour éviter qu’ensuite SID ne soit utilisé.

@Zargos, Est-ce que cela signifierait qu’avec ça je n’aurai plus besoin d’aller chercher les drivers sur le site officiel de Nvidia après chaque mise à jour automatique du kernel ?
A chaque fois qu’il sort un nouveau kernel, je suis contraint de relancer l’installation du driver Nvidia pour ma Geforce 4060 TI.

@Zargos

Et bien j’ai suivi cette procédure mais ca ne marche pas.
Après une longue procédure d’installation, quand je redémarre l’ordinateur reste bloqué sur cet écran
PXL_20241120_190826679.MP

il y a un autre « failed » plus haut :
Failed to start systemd-modules-load.service - Load Kernel Modules.
See ‹ systemctl status systemd-module-load.service › for details

Puis donc
Failed to start nvidia-persistence…ervice - NVIDIA Persistence Daemon.
See ‹ systemctl status nvidia-persistenced.service › for details.

Il faut aller voir dans les logs pour savoir ce qui se passe. C’est d’ailleurs ce que tu dit le message d’erreur.

Si tu fait CTRL+ALT+F2 par exemple, arrives-tu sur la console ?

Bon et bien j’ai du réinstaller.
Je suis donc avec une nouvelle installation de bookworm, avec les options acpi_osi=Linux pci=nomsi au noyau, pas de /home séparé. J’ai choisi uniquement l’environnement de bureau LXQt avec les utilitaires usuels du système. J’ai :

  • procédé à une mise à jour des paquets
  • ajouté mon compte d’utilisateur au groupe sudo
  • créé un fichier autologin pour ne pas à avoir à taper mon mdp en début de session (ce qui m’arrange car il y a un bug d’affichage lors de l’ouverture de la session et je dois taper un peu à l’aveugle) car je n’ai pas trouvé comment le faire dans les interfaces graphiques
  • installé timeshiht et créer une première sauvegarde (sans exclure root ni le compte utilisateur, avec les fichier cachés)

lspci -v | awk '/3D|VGA/' RS=

donne

01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce 9300M GS] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. U6V laptop
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at dc00 [size=128]
Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: nouveau
Kernel modules: nouveau

La commande

free -mh

donne

total utilisé libre partagé tamp/cache disponible
Mem: 2,9Gi 1,6Gi 488Mi 31Mi 1,1Gi 1,3Gi
Échange: 9,3Gi 0B 9,3Gi

Malgré la RAM physiquement présente de 4Go
(oui je n’ai pas fait dans le détail pour l’espace swapp, mais j’ai de la place)
La commande

glxinfo | grep -i 'device\|memory'

donne

Device: NV98 (0x6e9)
Video memory: 500MB
Unified memory: no
Memory info (GL_ATI_meminfo):
VBO free memory - total: 400 MB, largest block: 400 MB
VBO free aux. memory - total: 838860 MB, largest block: 838860 MB
Texture free memory - total: 400 MB, largest block: 400 MB
Texture free aux. memory - total: 838860 MB, largest block: 838860 MB
Renderbuffer free memory - total: 400 MB, largest block: 400 MB
Renderbuffer free aux. memory - total: 838860 MB, largest block: 838860 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 500 MB
Total available memory: 1049076 MB
Currently available dedicated video memory: 400 MB
GL_NVX_gpu_memory_info, GL_NV_conditional_render, GL_NV_copy_image,
GL_MESA_window_pos, GL_NVX_gpu_memory_info, GL_NV_ES1_1_compatibility,

A priori je n’ai pas encore d’installé le driver nouveau, en tout cas je ne le vois pas dans Synaptic… pour l’instant j’ai laissé la liste des dépots d’origine avec seulement bookworm main non-free-firmware dans /etc/apt/sources.list
En faisant une recherche pour nouveau je vois ces deux paquets installés libdrm-nouveau2 et xserver-xorg-video-nouveau
J’ai par contre le paquet intel-microcode installé dans sa dernière version.

Une petite conclusion sur ce sujet, et sur le hors-sujet /expérimental (SID dans bookworm).

Le sujet: « analyse de la différence de mémoire partagée selon la taille de mémoire RAM installée. »
Sujet techniquement intéressant, puisque rarement observé.

La mémoire globale utilisable par le système inclus RAM physique + swap éventuellement disponible. Pour un IGPU (fonction graphique dans le CPU), ou fonction graphique implantée sur la carte mère, le graphisme utilisera une portion de RAM incrémentée par blocs de 256M. Le graphisme n’utilisera pas le swap.

Au boot, le noyau analyse la configuration en réservant minimum 256M de RAM pour la graphisme, suffisant pour faire fonctionner un environnement bureautique.
Si le BIOS a un réglage permettant de contraindre une valeur max de RAM pour le graphique, il prendra cette valeur en considération, sinon, estimera la valeur la plus judicieuse à réserver, en s’assurant que ce qui reste de RAM+SWAP permette de faire de faire fonctionner le système.
Il n’est donc pas ‹ anormal › que le calcul de RAM graphique pour le noyau soit dépendant de la taille physique RAM, et des propriétés annoncées par la carte graphique. Difficile d’être plus précis dans l’analyse.
En résumé, le noyau ajustera dynamiquement ce dont il a besoin que le système fonctionne globalement.

Le sujet n’était donc pas un problème de performances graphique, ni même le mot ‹ nvidia › prononcé dans le sujet.

Quelques mots concernant la partie expérimentale proposée.
Avoir un apriori sur le driver nouveau avant même d’avoir analysé la partie graphique plus en détail, pour justifier l’expérience SID n’aurait pas du avoir lieu dans ce sujet.
La carte ‹ GeForce 9300M › est une génération de techno Tesla/2008, et le BIOS date de 2009.
Le driver nouveau est subdivisé en 15 niveaux de spécification selon l’historique de technologie.
Si aucun problème de performance n’est signalé, pas la peine de compliquer au risque de casser le système, et encore moins de s’aventurer dans une expérience SID dont le résultat était connu à l’avance (une analyse d’une minute suffit), en laissant imaginer ce qui se passerait lors d’un changement de noyau.

Le module ‹ nouveau › provient de l’installation de linux-image, et nécessite le driver xserver-xorg-video-nouveau qui fournit /usr/lib/xorg/modules/drivers/nouveau_drv.so

$ /sbin/modinfo nouveau |awk '/filename/{print $2}'
  /lib/modules/6.11.9-amd64/kernel/drivers/gpu/drm/nouveau/nouveau.ko.xz

Le module nouveau mériterait un sujet complet à lui seul, surtout pour aborder la partie firmware un peu plus délicate selon la génération ‹ legacy › ou non. Le firmware potentiellement manquant n’est pas nécessairement identifié/réclamé au boot dans les logs, mais peut être demandé dynamiquement pour activer l’accélération matérielle potentiellement possible pour la GPU (déport du calcul graphique du CPU système vers le CPU carte graphique, pour lecture video). → voir ce sujet pour complément.

Conclusion finalement moins petite que prévu.

@Verner merci pour le temps que tu as consacré à cette analyse et pour cette conclusion… qui en éclairera certainement d’autres davantage que moi, mais ça c’est du à mes connaissances sinon cela semble a peu près clair pour moi.
En tout cas me voilà rassuré :slight_smile: