1

Non mais oh !
350 Mo de mémoire consommée pour seulement le gestionnaire de bureau !
Mais je rêve !!!!

2

Peut-être, mais quelle gestion de bureau aussi, faut dire ce qui est !!!
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

3

Mmmmmm....
Je sens que le prochain preos verra une légère inflation sur sa taille embarrassed

4

(et puis dans un autre genre la consommation cpu de gnome-shell avec les applications en plein écran est aussi inacceptable !)

5

Je pense que depuis cet article gnome-shell a pris pas mal de poids: http://l3net.wordpress.com/2013/03/17/a-memory-comparison-of-light-linux-desktops/

cmp-all4.png

6

PpHd (./3) :
Je sens que le prochain preos verra une légère inflation sur sa taille

Ah ben parlons des nouvelles features alors, pour savoir comment minimiser leur empreinte mémoire chapo
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

7

Justement, PpHd voulait intégrer gnome-shell à PreOS embarrassed

8

Tout à fait. Ca ferra la même chose qu'avant mais ca prendra 10x plus de place tongue

9

Ok. Inutile, perte de place, impossible, ça c'est un challenge top
Ya un repo public, que j'attaque de mon côté ? smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

10

Ah putain, rien que de revoir le nom de Window Maker, ça me rapelle des putains de bons souvenirs, je l'aimais ce WM heart
Et aussi parce que sur mon petit Athon 2800+ avec 512 mo de ram, il me bouffait pas tout comme GNOME ou KKDE

11

Fluxbox ne bouffe toujours rien à mon petit i5 + 8Go grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

12

Et gnome-shell bouffe 350 Mo sad
(Ce sont des irresponsables qui codent, c'est pas possible).

13

"Bah tu sais, c'est pas grave, autant faire un malloc de trop, de toutes manières, vu le prix de la RAM aujourd'hui"©
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

14

"Optimiser ? Je connais pas ce mot"

15

(ça m'amuse que ce soit PpHd qui dise ça, lui qui défend l'overcommit sur l'autre topic tongue)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

16

l'over-commit ne coute rien, enfin, je vais pas rentrer dans ton troll embarrassed
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

17

(L'overcommit n'a rien à voir. Je parle de mémoire réellement allouée et utilisé par gnome shell. Pas de sa mémoire virtuelle. En mémoire virtuelle, il est à 2Go ! Un petit snapshop:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND  
 1348 pphd      20   0 1920772 428824  85292 S   0,0  2,6   2:25.55 gnome-shell  

)

18

En général, quand tu te préoccupes de la mémoire occupée, tu n'alloues pas non plus des pelletées en te disant "pas grave, je vais pas écrire dedans", mais bon ^^
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

19

Tu noteras d'ailleurs que le graphe que tu as mis est complètement faussé, car il ignore purement et simplement les optimisations de mémoire des environnements. Par exemple, KDE à vide prend beaucoup de place, car il précharge toutes les libraries. L'intérêt, c'est que quand tu lances une application KDE il forke le launcher, ce qui permet de bénéficer à fond du copy-on-write : en plus des pages de code, l'essentiel des pages de données et une bonne partie de la pile sont communes également.

J'ignore si gnome-shell fait la même chose, mais ça serait très possible. C'est un gain important en consommation mémoire et en temps (le linkage dynamique est en grande partie fait). Mais ça a pour effet que les outils type ps / top imputent la mémoire au shell au lieu des applications.

Au lieu de te tapper un shell à 30Mo + 10 applications à 50Mo (soit un total de 530), par exemple, tu auras un shell à 50 + 10 applications à 40Mo (soit un total de 450).

C'est un peu schématisé mais c'est l'idée. Oh et comme effet secondaire, ça fait râler les utilisateurs qui ne voient que "50Mo c'est plus gros que 30Mo", et ne font pas le rapprochement avec le gain sur les autres applications.
D'autant plus que le gain n'est pas évident car elles "consomment" toujours autant, c'est simplement que la quantité en "shared" est plus grande.

20

Zerosquare (./18) :
En général, quand tu te préoccupes de la mémoire occupée, tu n'alloues pas non plus des pelletées en te disant "pas grave, je vais pas écrire dedans", mais bon ^^

Pourquoi ? C'est de la mémoire virtuelle. C'est une ressource 100% alloué au processus, et qui ne se partage pas avec les autres process.

21

spectras (./19) :
Tu noteras d'ailleurs que le graphe que tu as mis est complètement faussé, car il ignore purement et simplement les optimisations de mémoire des environnements. Par exemple, KDE à vide prend beaucoup de place, car il précharge toutes les libraries. L'intérêt, c'est que quand tu lances une application KDE il forke le launcher, ce qui permet de bénéficer à fond du copy-on-write : en plus des pages de code, l'essentiel des pages de données et une bonne partie de la pile sont communes également.

J'ignore si gnome-shell fait la même chose, mais ça serait très possible. C'est un gain important en consommation mémoire et en temps (le linkage dynamique est en grande partie fait). Mais ça a pour effet que les outils type ps / top imputent la mémoire au shell au lieu des applications.

Au lieu de te tapper un shell à 30Mo + 10 applications à 50Mo (soit un total de 530), par exemple, tu auras un shell à 50 + 10 applications à 40Mo (soit un total de 450).

C'est un peu schématisé mais c'est l'idée. Oh et comme effet secondaire, ça fait râler les utilisateurs qui ne voient que "50Mo c'est plus gros que 30Mo", et ne font pas le rapprochement avec le gain sur les autres applications.
D'autant plus que le gain n'est pas évident car elles "consomment" toujours autant, c'est simplement que la quantité en "shared" est plus grande.

C'est l'excuse que j'entends le plus souvent. Et elle le plus souvent complément foireuse. Je n'ai compté que la mémoire RES, et pas la mémoire partagé entre process ! (Je n'ai pas essayé avec KDE).
On parle de 350 Mega vs 12Mo ! Et tu pourras lancer autant d'application KDE ou gnome, ca ne bouffera jamais autant.

22

PpHd (./21) :
Je n'ai compté que la mémoire RES, et pas la mémoire partagé entre process ! (Je n'ai pas essayé avec KDE).

La mémoire RES inclue les zone partagées entre les processus.
C'est juste deux indicateurs décorrelés. RES indique juste que la mémoire n'a pas été déchargée dans le swap. Elle peut tout à fait être partagée quand même.

En plus de ça, SHR ne comptabilise pas toute la mémoire partagée. À commencer par les segments de mémoire partagés (qu'on obtient avec shmget). Ceux là sont bien comptés comme VIRT et comme RES s'ils sont en mémoire, mais pas comme SHR, même si 30 processus y accèdent.

[edit: j'ai retrouvé cet excellent post sur les mesures de mémoire et pourquoi, justement, les outils de ce type ne permettent pas d'évaluer l'usage mémoire réel d'une application]

23

./22: J'avais oublié. Mais ca n'empeche pas d'être un veau.cf. ./17. Et les segments partagés ne sont plus utilisés il me semble, non ?

24

Il y a encore quelques applications qui s'en servent. PostgreSQL et MySQL pour ne citer que deux applis que je connais, mais c'est sans doute pas les seuls. Il n'y a pas vraiment d'autre solution pour disposer de mémoire partagée de façon portable. Sous Linux on peut faire des mmap anonymous+shared, ou alors utiliser shm_open, mais le support de l'un comme de l'autre est loin d'être aussi portable qu'un shmget. Sans compter qu'il est très probable que ça ne soit pas non plus comptabilisé comme SHR.

Tiens pour ajouter un petit exemple, je suis en train de faire du debugging de trucs. Là j'ai 20 process Apache ouverts, avec 800M de RES et 20M de SHR chacun. La machine a 2Go de mémoire et 1Go de swap. Et free me dit que j'ai encore 400Mo de libres (en +/- buffers/cache).

25

Vince, Zero, Folco smile

GT Pas éqipé de 4 gigas !!
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !