Chez moi, apr�s un boot (2.4.18 aussi :-(): MemTotal: 124496 kB MemFree: 100128 kB MemShared: 0 kB Buffers: 1768 kB Cached: 12736 kB SwapCached: 0 kB Active: 4860 kB Inactive: 16296 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 124496 kB LowFree: 100128 kB SwapTotal: 266072 kB SwapFree: 266072 kB
Et voici ce que �a signifie :
MemTotal: Total usable ram (i.e. physical ram minus a few reserved
bits and the kernel binary code)
MemFree: The sum of LowFree+HighFree
Buffers: Relatively temporary storage for raw disk blocks
shouldn't get tremendously large (20MB or so)
Cached: in-memory cache for files read from the disk (the
pagecache). Doesn't include SwapCached
SwapCached: Memory that once was swapped out, is swapped back in but
still also is in the swapfile (if memory is needed it
doesn't need to be swapped out AGAIN because it is already
in the swapfile. This saves I/O)
Active: Memory that has been used more recently and usually not
reclaimed unless absolutely necessary.
Inactive: Memory which has been less recently used. It is more
eligible to be reclaimed for other purposes
HighTotal:
HighFree: Highmem is all memory above ~860MB of physical memory
Highmem areas are for use by userspace programs, or
for the pagecache. The kernel must use tricks to access
this memory, making it slower to access than lowmem.
LowTotal:
LowFree: Lowmem is memory which can be used for everything that
highmem can be used for, but it is also availble for the
kernel's use for its own data structures. Among many
other things, it is where everything from the Slab is
allocated. Bad things happen when you're out of lowmem.
SwapTotal: total amount of swap space available
SwapFree: Memory which has been evicted from RAM, and is temporarily
on the diskNB:
- MemShared est obsol�te.
- La division en m�moire basse et haute est due � une limitation de l'architecture des PC. L'auteur de la doc n'est pas tr�s pr�cis quand il �crit que la m�moire est plus lente d'acc�s.
Sauf erreur, le probl�me est qu'elle n'est pas adressable par les p�riph�riques, donc si des donn�es arrivent d'un contr�leur disque/r�seau/autre, elles doivent d'abord �tre �crite en m�moire basse avant d'�tre copi�e par le CPU en haut. On appelle bounce buffer la m�moire basse utilis�e pour cela.
Toujours sur x86, il existe un moyen d'adresser plus de 4 Go de m�moire physique, mais l� il s'agit vraiment d'une horreur digne du temps du 8086 (o� il s'agissait d'adresser plus de 64 Ko). Je ne sais pas comment Linux rapporte la quantit� de cette m�moire.
Un sync n'y change rien :-(
sync �crit sur disque ce qui a chang� en cache, mais ne vide pas pour autant les caches.
Peut-�tre qu'en mettant l'option sync dans le fstab ...
Il y aura toujours des caches, pour la lecture. En revanche l'�criture sur disque sera imm�diate.
Personnellement, je ne vois pas �a comme un bug ni un probl�me , je voulais juste savoir si vous aviez constater la m�me chose. Visiblement pas pour tout le monde ...
AMHA tout le monde doit constater cela, quel que soit l'OS, sauf � remonter dans les ann�es 1980.
Marc Mongenet
_______________________________________________ gull mailing list [EMAIL PROTECTED] http://lists.alphanet.ch/mailman/listinfo/gull
