On a 2.0.36 kernel the above-referenced mb
shows:
dragonwind:/proc# cat cpuinfo
processor : 0
cpu : ?86
model : 386 SX/DX
vendor_id : GenuineIntel
At the least, java breaks because of the '?' char.
Is the problem is due to the older 2.0.36 kernel,
or would the problem also present itself on a newer 2.2.x kernel?
Annette
On Sun, 18 Mar 2001 [email protected] wrote:
> On a 2.0.36 kernel the above-referenced mb
> shows:
> ...
> Is the problem is due to the older 2.0.36 kernel,
Yes.
> or would the problem also present itself on a newer 2.2.x kernel?
Current 2.2 and 2.4 are both fixed for this problem.
This and a few other CPU related fixes should probably be backported
to 2.0 if someone has the spare time.
regards,
Dave.
--
| Dave Jones. http://www.suse.de/~davej
| SuSE Labs
Linux version 2.4.3-pre4 (root@stucko) (gcc version 2.95.3 20010219 (prerelease)) #1 Sun Mar 18 01:29:02 EST 2001
BIOS-provided physical RAM map:
BIOS-88: 000000000009f000 @ 0000000000000000 (usable)
BIOS-88: 0000000001700000 @ 0000000000100000 (usable)
On node 0 totalpages: 6144
zone(0): 4096 pages.
zone(1): 2048 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=Linux ro root=302
Initializing CPU#0
Detected 83.524 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 166.29 BogoMIPS
Memory: 22124k/24576k available (996k kernel code, 2064k reserved, 382k data, 60k init, 0k highmem)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
CPU: Before vendor init, caps: 0000013f 00000000 00000000, vendor = 0
Intel Pentium with F0 0F bug - workaround enabled.
CPU: After vendor init, caps: 0000013f 00000000 00000000 00000000
CPU: After generic, caps: 0000013f 00000000 00000000 00000000
CPU: Common caps: 0000013f 00000000 00000000 00000000
CPU: Intel OverDrive PODP5V83 stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
isapnp: Scanning for Pnp cards...
isapnp: Card 'Adaptec AVA-1505AI'
isapnp: Card '3Com 3C509B EtherLink III'
isapnp: 2 Plug & Play cards detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
parport0: PC-style at 0x378 [PCSPP(,...)]
pty: 256 Unix98 ptys configured
block: queued sectors max/low 14605kB/4868kB, 64 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
hda: ST3491A D, ATA DISK drive
hdb: QUANTUM PD210A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 836070 sectors (428 MB) w/120KiB Cache, CHS=899/15/62
hdb: 408564 sectors (209 MB) w/32KiB Cache, CHS=873/13/36
Partition check:
hda: hda1 hda2
hdb: hdb1 hdb2
paride: epat registered as protocol 0
pd: pd version 1.05, major 45, cluster 64, nice 0
pda: Sharing parport0 at 0x378
pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 1 (5/3), delay 1
pda: AVATAR AR2250, master, 489472 blocks [239M], (956/16/32), removable media
pda: pda1
Floppy drive(s): fd0 is 1.44M
FDC 0 is an 8272A
eth0: 3c509 at 0x220, 10baseT port, address 00 a0 24 46 41 c0, IRQ 5.
3c509.c:1.16 (2.2) 2/3/98 [email protected].
loop: loaded (max 8 devices)
Serial driver version 5.05 (2000-12-13) with ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16450
ttyS01 at 0x02f8 (irq = 3) is a 16450
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
ip_conntrack (192 buckets, 1536 max)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 60k freed
Adding Swap: 20568k swap-space (priority -1)
eth0: Setting Rx mode to 1 addresses.
aha152x: BIOS test: passed, detected 1 controller(s)
aha152x: resetting bus...
aha152x0: vital data: rev=3, io=0x140 (0x140/0x140), irq=10, scsiid=7, reconnect=enabled, parity=enabled, synchronous=disabled, delay=1000, extended translation=disabled
aha152x0: trying software interrupt, ok.
scsi0 : Adaptec 152x SCSI driver; $Revision: 2.4 $
request_module[scsi_hostadapter]: waitpid(296,...) failed, errno 512
Detected scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type -1
resize_dma_pool: unknown device type -1
aha152x: timer expired
Unable to handle kernel NULL pointer dereference at virtual address 000000fb
printing eip:
c2016531
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c2016531>]
EFLAGS: 00010082
eax: 00000000 ebx: c0709dc8 ecx: c10e3a60 edx: c1258800
esi: 00000000 edi: 00000082 ebp: c1258878 esp: c0709f54
ds: 0018 es: 0018 ss: 0018
Process scsi_eh_0 (pid: 297, stackpage=c0709000)
Stack: 00000282 c1258800 00000000 c1274a00 c20165cf c1258800 c1258878 00000282
c1274a00 c019dddf c1274a00 00002003 00000000 c019e427 c1274a00 c0708000
c0709fdc c0709fdc c1258800 c0709fe8 c0709fe8 c10e3a60 00000000 c019e8fb
Call Trace: [<c20165cf>] [<c019dddf>] [<c019e427>] [<c019e8fb>] [<c010742c>]
Code: f6 80 fb 00 00 00 10 75 70 8b 4d 00 31 d2 eb 0a 89 ca 8b 82
On Sun, Mar 18, 2001 at 08:07:20PM -0600, [email protected] wrote:
> On a 2.0.36 kernel the above-referenced mb
> shows:
>
> dragonwind:/proc# cat cpuinfo
> processor : 0
> cpu : ?86
> model : 386 SX/DX
> vendor_id : GenuineIntel
>
> At the least, java breaks because of the '?' char.
>
> Is the problem is due to the older 2.0.36 kernel,
> or would the problem also present itself on a newer 2.2.x kernel?
Ahhhh, bit by the "IV written as 15 by Intel"-bug.
I'll hack up a fix to apply against v2.0.39.
And no, you won't be bit by this bug in a recent v2.2 or v2.4 kernel.
/David
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
Linux version 2.4.3-pre4 (root@stucko) (gcc version 2.95.3 20010219 (prerelease)) #1 Sun Mar 18 01:29:02 EST 2001
BIOS-provided physical RAM map:
BIOS-88: 000000000009f000 @ 0000000000000000 (usable)
BIOS-88: 0000000001700000 @ 0000000000100000 (usable)
On node 0 totalpages: 6144
zone(0): 4096 pages.
zone(1): 2048 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=Linux ro root=302
Initializing CPU#0
Detected 83.524 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 166.29 BogoMIPS
Memory: 22124k/24576k available (996k kernel code, 2064k reserved, 382k data, 60k init, 0k highmem)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
CPU: Before vendor init, caps: 0000013f 00000000 00000000, vendor = 0
Intel Pentium with F0 0F bug - workaround enabled.
CPU: After vendor init, caps: 0000013f 00000000 00000000 00000000
CPU: After generic, caps: 0000013f 00000000 00000000 00000000
CPU: Common caps: 0000013f 00000000 00000000 00000000
CPU: Intel OverDrive PODP5V83 stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
isapnp: Scanning for Pnp cards...
isapnp: Card 'Adaptec AVA-1505AI'
isapnp: Card '3Com 3C509B EtherLink III'
isapnp: 2 Plug & Play cards detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
parport0: PC-style at 0x378 [PCSPP(,...)]
pty: 256 Unix98 ptys configured
block: queued sectors max/low 14605kB/4868kB, 64 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
hda: ST3491A D, ATA DISK drive
hdb: QUANTUM PD210A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 836070 sectors (428 MB) w/120KiB Cache, CHS=899/15/62
hdb: 408564 sectors (209 MB) w/32KiB Cache, CHS=873/13/36
Partition check:
hda: hda1 hda2
hdb: hdb1 hdb2
paride: epat registered as protocol 0
pd: pd version 1.05, major 45, cluster 64, nice 0
pda: Sharing parport0 at 0x378
pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 1 (5/3), delay 1
pda: AVATAR AR2250, master, 489472 blocks [239M], (956/16/32), removable media
pda: pda1
Floppy drive(s): fd0 is 1.44M
FDC 0 is an 8272A
eth0: 3c509 at 0x220, 10baseT port, address 00 a0 24 46 41 c0, IRQ 5.
3c509.c:1.16 (2.2) 2/3/98 [email protected].
loop: loaded (max 8 devices)
Serial driver version 5.05 (2000-12-13) with ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16450
ttyS01 at 0x02f8 (irq = 3) is a 16450
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
ip_conntrack (192 buckets, 1536 max)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 60k freed
Adding Swap: 20568k swap-space (priority -1)
eth0: Setting Rx mode to 1 addresses.
aha152x: BIOS test: passed, detected 1 controller(s)
aha152x: resetting bus...
aha152x0: vital data: rev=3, io=0x140 (0x140/0x140), irq=10, scsiid=7, reconnect=enabled, parity=enabled, synchronous=disabled, delay=1000, extended translation=disabled
aha152x0: trying software interrupt, ok.
scsi0 : Adaptec 152x SCSI driver; $Revision: 2.4 $
request_module[scsi_hostadapter]: waitpid(296,...) failed, errno 512
Detected scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type -1
resize_dma_pool: unknown device type -1
aha152x: timer expired
Unable to handle kernel NULL pointer dereference at virtual address 000000fb
printing eip:
c2016531
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c2016531>]
EFLAGS: 00010082
eax: 00000000 ebx: c0709dc8 ecx: c10e3a60 edx: c1258800
esi: 00000000 edi: 00000082 ebp: c1258878 esp: c0709f54
ds: 0018 es: 0018 ss: 0018
Process scsi_eh_0 (pid: 297, stackpage=c0709000)
Stack: 00000282 c1258800 00000000 c1274a00 c20165cf c1258800 c1258878 00000282
c1274a00 c019dddf c1274a00 00002003 00000000 c019e427 c1274a00 c0708000
c0709fdc c0709fdc c1258800 c0709fe8 c0709fe8 c10e3a60 00000000 c019e8fb
Call Trace: [<c20165cf>] [<c019dddf>] [<c019e427>] [<c019e8fb>] [<c010742c>]
Code: f6 80 fb 00 00 00 10 75 70 8b 4d 00 31 d2 eb 0a 89 ca 8b 82
Greetings,
I have a server farm made of identical hardware running pop3 and imap mail
functions. recently, we upgraded all the machines to kernel 2.4.2, but we
noticed that according to free, our memory utilization went way up. Here
is the output of free on the 2.4.2 machine:
total used free shared buffers cached
Mem: 513192 492772 20420 0 1684 263188
-/+ buffers/cache: 227900 285292
Swap: 819304 540 818764
On the 2.2..18 machine:
total used free shared buffers cached
Mem: 517256 351280 165976 19920 82820 186836
-/+ buffers/cache: 81624 435632
Swap: 819304 0 819304
Doing the math, the 2.4 machine is using 44% of available memory, while
the 2.2 is using only about 14%.
Here are the contents of /proc/meminfo on 2.4:
total: used: free: shared: buffers: cached:
Mem: 525508608 517480448 8028160 0 1138688 282091520
Swap: 838967296 552960 838414336
MemTotal: 513192 kB
MemFree: 7840 kB
MemShared: 0 kB
Buffers: 1112 kB
Cached: 275480 kB
Active: 254876 kB
Inact_dirty: 18880 kB
Inact_clean: 2836 kB
Inact_target: 48 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 513192 kB
LowFree: 7840 kB
SwapTotal: 819304 kB
SwapFree: 818764 kB
on 2.2:
total: used: free: shared: buffers: cached:
Mem: 529670144 366837760 162832384 22945792 84807680 194367488
Swap: 838967296 0 838967296
MemTotal: 517256 kB
MemFree: 159016 kB
MemShared: 22408 kB
Buffers: 82820 kB
Cached: 189812 kB
SwapTotal: 819304 kB
SwapFree: 819304 kB
These machines are dual P2-400's, with 512M ECC ram, adaptec 2940, and
dual intel etherexpress pro 100 cards.
I also tried 2.4.2-ac20 with similar results.
Am I missing something here? I'd really like to move the farm back up to
2.4 series.
Thanks,
Josh
---
Josh Grebe
Senior Unix Systems Administrator
Primary Network, an MPower Company
http://www.primary.net
On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> Greetings,
...
> Doing the math, the 2.4 machine is using 44% of available memory, while
> the 2.2 is using only about 14%.
How is the performance difference ?
...
> These machines are dual P2-400's, with 512M ECC ram, adaptec 2940, and
> dual intel etherexpress pro 100 cards.
>
> I also tried 2.4.2-ac20 with similar results.
>
> Am I missing something here? I'd really like to move the farm back up to
> 2.4 series.
Free memory is wasted memory. It seemed like 2.4 wasted a lot less memory
than 2.2 on your workload.
Could you do some performance measurements (eg. average latency on IMAP
connection or something like that) ? It would be great to know wheter
2.4 is better or worse than 2.2 (it's most likely better, since it probably
uses the memory better, but it would be nice to know)
--
................................................................
: [email protected] : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob ?stergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> Greetings,
>
> I have a server farm made of identical hardware running pop3 and imap mail
> functions. recently, we upgraded all the machines to kernel 2.4.2, but we
> noticed that according to free, our memory utilization went way up. Here
> is the output of free on the 2.4.2 machine:
> total used free shared buffers cached
> Mem: 513192 492772 20420 0 1684 263188
> -/+ buffers/cache: 227900 285292
> Swap: 819304 540 818764
>
>
> On the 2.2..18 machine:
> total used free shared buffers cached
> Mem: 517256 351280 165976 19920 82820 186836
> -/+ buffers/cache: 81624 435632
> Swap: 819304 0 819304
>
>
> Doing the math, the 2.4 machine is using 44% of available memory, while
> the 2.2 is using only about 14%.
What does /proc/slabinfo report for the number of pages locked down in
the inode and dentry caches? My machine has pretty much every inode in
memory and is using close to 50% of my memory for these (214MB/512MB).
These caches do not seem to be counted towards 'reclaimable' memory by
the new VM and are only pruned when _all_ other attempts to free up
memory have failed.
This becomes very noticeable on a not very fast, small memory machine
(i.e. 48MB sparc-IPC), where 2.2 stays relatively snappy, but 2.4
becomes unusable after an updatedb run.
Jan
slabinfo reports:
inode_cache 189974 243512 480 30439 30439 1 : 124 62
dentry_cache 201179 341940 128 11398 11398 1 : 252 126
However, I am hard pressed to find documentation on how to actually read
this data, especially on a SMP box. Could someone give me a brief
runwdown?
Also, if this memory is cached, wouldn't it make sense if it were reported
as part of the total cached memory in /proc/meminfo? And can this
behavior be tuned so that it uses less of the overall memory?
Thanks,
Josh
---
Josh Grebe
Senior Unix Systems Administrator
Primary Network, an MPower Company
http://www.primary.net
On Tue, 20 Mar 2001, Jan Harkes wrote:
> On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> > Greetings,
> >
> > I have a server farm made of identical hardware running pop3 and imap mail
> > functions. recently, we upgraded all the machines to kernel 2.4.2, but we
> > noticed that according to free, our memory utilization went way up. Here
> > is the output of free on the 2.4.2 machine:
> > total used free shared buffers cached
> > Mem: 513192 492772 20420 0 1684 263188
> > -/+ buffers/cache: 227900 285292
> > Swap: 819304 540 818764
> >
> >
> > On the 2.2..18 machine:
> > total used free shared buffers cached
> > Mem: 517256 351280 165976 19920 82820 186836
> > -/+ buffers/cache: 81624 435632
> > Swap: 819304 0 819304
> >
> >
> > Doing the math, the 2.4 machine is using 44% of available memory, while
> > the 2.2 is using only about 14%.
>
> What does /proc/slabinfo report for the number of pages locked down in
> the inode and dentry caches? My machine has pretty much every inode in
> memory and is using close to 50% of my memory for these (214MB/512MB).
>
> These caches do not seem to be counted towards 'reclaimable' memory by
> the new VM and are only pruned when _all_ other attempts to free up
> memory have failed.
>
> This becomes very noticeable on a not very fast, small memory machine
> (i.e. 48MB sparc-IPC), where 2.2 stays relatively snappy, but 2.4
> becomes unusable after an updatedb run.
>
> Jan
>
As far as performance goes, I can only say that my max load is slightly
lower on the 2.4 box then on the 2.2 boxes. Our average load for yesterday
on 2.4 was .23, with a max of 1.11. In comparison, my averages for the
other machines are .27, .27, .23, and .23. The maxes are 1.85, 1.33, 2.06,
1.47.
As far as speed goes, I am not able to measure any real difference (only
testing pop3) between 2.2 and 2.4. I would blame this on the NAS device, a
NetApp Filer F760 being only able to push about 110mbit sustained on the
gig-e network.
Thanks,
Josh
---
Josh Grebe
Senior Unix Systems Administrator
Primary Network, an MPower Company
http://www.primary.net
On Tue, 20 Mar 2001, [iso-8859-1] Jakob ?stergaard wrote:
> On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> > Greetings,
> ...
> > Doing the math, the 2.4 machine is using 44% of available memory, while
> > the 2.2 is using only about 14%.
>
> How is the performance difference ?
>
> ...
> > These machines are dual P2-400's, with 512M ECC ram, adaptec 2940, and
> > dual intel etherexpress pro 100 cards.
> >
> > I also tried 2.4.2-ac20 with similar results.
> >
> > Am I missing something here? I'd really like to move the farm back up to
> > 2.4 series.
>
> Free memory is wasted memory. It seemed like 2.4 wasted a lot less memory
> than 2.2 on your workload.
>
> Could you do some performance measurements (eg. average latency on IMAP
> connection or something like that) ? It would be great to know wheter
> 2.4 is better or worse than 2.2 (it's most likely better, since it probably
> uses the memory better, but it would be nice to know)
>
> --
> ................................................................
> : [email protected] : And I see the elder races, :
> :.........................: putrid forms of man :
> : Jakob ?stergaard : See him rise and claim the earth, :
> : OZ9ABN : his downfall is at hand. :
> :.........................:............{Konkhra}...............:
>
On Tue, 20 Mar 2001, Josh Grebe wrote:
> slabinfo reports:
>
> inode_cache 189974 243512 480 30439 30439 1 : 124 62
> dentry_cache 201179 341940 128 11398 11398 1 : 252 126
^
<name> <used> <allocd> | <used> <allocd>
<in objects> <size> <in pages>
> However, I am hard pressed to find documentation on how to actually
> read this data, especially on a SMP box. Could someone give me a brief
> runwdown?
See above. The columns further to the right are debugging info.
> Also, if this memory is cached, wouldn't it make sense if it were
> reported as part of the total cached memory in /proc/meminfo?
I'd definately like to see this. It would be great if somebody
would sit down and implement this. <hint> <hint>
> And can this behavior be tuned so that it uses less of the overall
> memory?
This isn't currently possible. Also, I suspect what we really want
for most situations is a way to better balance between the different
uses of memory. Again, patches are welcome (I haven't figured out a
way to take care of this balancing yet ... maybe we DO want some way
of limiting memory usage of each subsystem??).
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
:: > And can this behavior be tuned so that it uses less of the overall
:: > memory?
::
:: This isn't currently possible. Also, I suspect what we really want
:: for most situations is a way to better balance between the different
:: uses of memory. Again, patches are welcome (I haven't figured out a
:: way to take care of this balancing yet ... maybe we DO want some way
:: of limiting memory usage of each subsystem??).
man ulimit? ;-)
On a more serious note, is there a way to find out what has been paged out
to disk, and also limit what can be paged out?
I could be wrong, but for instance I leave X running for a while (not sure
about the timing here but let's say several hours), and come back and log in
again, it is very slow to "come alive". The screen redraws slowly, and
there's quite a bit of disk access. This only happens if the system is left
alone for a long period of time (no, I don't have APM running on it).
Squid behaves the same -- the first access after a long period of inactivity
causes a lot of disk grinding, but successive accesses are fine.
Don't see this behaviour with the 2.2.x kernels.
-- Juha
> > slabinfo reports:
> >
> > inode_cache 189974 243512 480 30439 30439 1 : 124 62
> > dentry_cache 201179 341940 128 11398 11398 1 : 252 126
> ^
> <name> <used> <allocd> | <used> <allocd>
> <in objects> <size> <in pages>
>
Then how to interpret slabinfo in 2.2.16 box?
e.g. grep cache /proc/slabinfo
kmem_cache 32 42
skbuff_head_cache 2676 2730
dentry_cache 15626 16988
files_cache 103 108
uid_cache 10 127
slab_cache 85 126
what does those numbers mean?
Furthermore, are those cache info above reported as part of the total
cache in /proc/meminfo ?
Lastly, which cache can be reclaimed, and which can't?
I am doing some memory measurements in 2.2.16 linux box. Thanks in advance!
--
Cheers!
--Zou Min
Zou Min writes:
> Then how to interpret slabinfo in 2.2.16 box?
> e.g. grep cache /proc/slabinfo
>
> kmem_cache 32 42
> skbuff_head_cache 2676 2730
> dentry_cache 15626 16988
> files_cache 103 108
> uid_cache 10 127
> slab_cache 85 126
>
> what does those numbers mean?
First number is in-use objects in that cache, second number is
currently-allocated objects in that cache.
> Furthermore, are those cache info above reported as part of the total
> cache in /proc/meminfo ?
Don't know.
> Lastly, which cache can be reclaimed, and which can't?
Slab cache will shrink if there are whole pages which are empty (it may
be that they have to be at the end of the cache). It is hard to tell
from the above numbers if any of the caches could shrink, because it
depends on the number of objects per page, and if there are any whole
pages without allocated objects.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
> inode_cache 189974 243512 480 30439 30439 1 : 124 62
> dentry_cache 201179 341940 128 11398 11398 1 : 252 126
1) number of used objects
2) number of allocated objects
3) size of each object
4) number of slabs that are at least partially in use
5) number of slabs that are allocated for the cache
i.e. 5)-4) are the number of freeable slabs in the cache
6) size in pages for a slab
:
7) length of the per-cpu list. Each cpu some objects in a local list it
can use without acquiring a spinlock
8) batch count. If the per-cpu list overflows multiple objects are
freed/allocated in one block.
7 and 8 are only present if your kernel is compiled for SMP, root can
tune them with
#echo "<slab name> <length> <batchcount>" > /proc/slabinfo
It seems that the dentry cache is severely fragmented, nearly 20 MB (or
30%) are
unfreeable due to fragmentation.
--
Manfred
> > Lastly, which cache can be reclaimed, and which can't?
>
> Slab cache will shrink if there are whole pages which are empty (it may
> be that they have to be at the end of the cache). It is hard to tell
> from the above numbers if any of the caches could shrink, because it
> depends on the number of objects per page, and if there are any whole
> pages without allocated objects.
Btw, how to know the size of each objects in different cache?
--
Cheers!
--Zou Min
This is what I'm afraid of, in my case we have millions of files that are
dealt with in no real order, and if cache fragmentation will keep the
memory from being freed, we're in for problems. This reading was taken
with the machine having been up for only 5 days. Currently, I show:
inode_cache 194565 234696 480 29337 29337 1 : 124 62
dentry_cache 207257 327300 128 10910 10910 1 : 252 126
However, memory usage is still at 44% according to /proc/meminfo.
I've had to put my SMTP box back to 2.2 as it was up to 90% memory used,
where the others were around 18%. I'm keeping the pop/imap server at 2.4
as 44% is standable, while not exactly desirable. I'm
---
Josh Grebe
Senior Unix Systems Administrator
Primary Network, an MPower Company
http://www.primary.net
On Wed, 21 Mar 2001, Manfred Spraul wrote:
> > inode_cache 189974 243512 480 30439 30439 1 : 124 62
> > dentry_cache 201179 341940 128 11398 11398 1 : 252 126
>
> 1) number of used objects
> 2) number of allocated objects
> 3) size of each object
> 4) number of slabs that are at least partially in use
> 5) number of slabs that are allocated for the cache
> i.e. 5)-4) are the number of freeable slabs in the cache
> 6) size in pages for a slab
> :
> 7) length of the per-cpu list. Each cpu some objects in a local list it
> can use without acquiring a spinlock
> 8) batch count. If the per-cpu list overflows multiple objects are
> freed/allocated in one block.
>
> 7 and 8 are only present if your kernel is compiled for SMP, root can
> tune them with
>
> #echo "<slab name> <length> <batchcount>" > /proc/slabinfo
>
> It seems that the dentry cache is severely fragmented, nearly 20 MB (or
> 30%) are
> unfreeable due to fragmentation.
>
> --
> Manfred
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Wed, Mar 21, 2001 at 11:42:08AM -0600, Josh Grebe wrote:
> This is what I'm afraid of, in my case we have millions of files that are
> dealt with in no real order, and if cache fragmentation will keep the
> memory from being freed, we're in for problems. This reading was taken
> with the machine having been up for only 5 days. Currently, I show:
You shouldn't worry too much about fragmentation within the slabcache.
It actually is designed to limit the amount of fragmentation. And the
next 100000 dentry/inode allocations will come at no cost ;)
The fact that your icache/dcache slabs are not 100% used indicates that
shrink_i/dcache_memory actually was triggered a couple of times due to
free memory shortage. In contrast, on my machine, the available and
allocated numbers are pretty much always identical. I'm probably not
putting enough VM pressure on the machine so the normal aging/pageout
mechanisms manage to free up just enough memory to avoid dentry/inode
pruning.
> I've had to put my SMTP box back to 2.2 as it was up to 90% memory used,
> where the others were around 18%. I'm keeping the pop/imap server at 2.4
> as 44% is standable, while not exactly desirable. I'm
Did the SMTP box become unusable? Although the VM ends up working with
only the memory that is not locked up in slabs, it does a pretty good
job, as you reported yourself.
On Tue, Mar 20, 2001 at 02:29:47PM -0600, Josh Grebe wrote:
> As far as performance goes, I can only say that my max load is slightly
> lower on the 2.4 box then on the 2.2 boxes. Our average load for yesterday
> on 2.4 was .23, with a max of 1.11. In comparison, my averages for the
> other machines are .27, .27, .23, and .23. The maxes are 1.85, 1.33, 2.06,
> 1.47.
>
> As far as speed goes, I am not able to measure any real difference (only
> testing pop3) between 2.2 and 2.4. I would blame this on the NAS device, a
> NetApp Filer F760 being only able to push about 110mbit sustained on the
> gig-e network.
Doing an (intuitive) cost/benefit analysis, throwing out an inode does
not guarantee to free up any memory. While throwing out clean pages from
the pagecache will free up some memory and they do not necessarily have
to be read back in at all (otherwise they would have been 'active').
I've been thinking about this a bit and one possible solution would be
to significantly lower the cost of prune_icache by removing the
sync_all_inodes and only let it prune inodes that do not have any
mappings associated with them. Then it might become possible to call it
more frequently, like every time we hit do_try_free_pages.
If there is enough memory available in the system, the inodes will have
mappings and won't be removed. Once memory pressure builds up the
mappings are cleaned and pruned, by the VM system and removing the
remains of the inode should be relatively inexpensive. There is probably
something that I missed, so I should just shut up now and write the code.
Jan
On Wed, 21 Mar 2001, Jan Harkes wrote:
> I've been thinking about this a bit and one possible solution would be
> to significantly lower the cost of prune_icache by removing the
> sync_all_inodes and only let it prune inodes that do not have any
> mappings associated with them. Then it might become possible to call
> it more frequently, like every time we hit do_try_free_pages.
Marcelo and me have been looking at this issue too, and have
come to almost the same conclusion as you, with one small
change.
We -need- to have a way to trigger the writeout of dirty
inodes under memory pressure. Imagine doing 'chown -R' on
a huge tree on a low-memory box; you'd end up with zillions
of dirty inodes in memory with no way to free them.
Now if prune_icache would write all the dirty inodes without
data pages to disk automatically, we'd have this issue fixed
and we'll be able to make a much more efficient prune_icache.
Anybody willing to give it a shot ?
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/