From: Zdenek Kabelac <zkabelac@redhat.com>
To: Markus <M4rkusXXL@web.de>
Cc: linux-kernel@vger.kernel.org,
Wu Fengguang <fengguang.wu@intel.com>,
linux-mm@kvack.org
Subject: Re: drop_caches ...
Date: Wed, 04 Mar 2009 15:09:44 +0100 [thread overview]
Message-ID: <49AE8BA8.3080504@redhat.com> (raw)
In-Reply-To: <200903041447.49534.M4rkusXXL@web.de>
Markus napsal(a):
>>>>>>> The memory mapped pages won't be dropped in this way.
>>>>>>> "cat /proc/meminfo" will show you the number of mapped pages.
>>>>>> # sync ; echo 3 > /proc/sys/vm/drop_caches ; free -m ;
>>>> cat /proc/meminfo
>>>>>> total used free shared buffers
>>>>>> cached
>>>>>> Mem: 3950 3262 688 0 0
>>>>>> 359
>>>>>> -/+ buffers/cache: 2902 1047
>>>>>> Swap: 5890 1509 4381
>>>>>> MemTotal: 4045500 kB
>>>>>> MemFree: 705180 kB
>>>>>> Buffers: 508 kB
>>>>>> Cached: 367748 kB
>>>>>> SwapCached: 880744 kB
>>>>>> Active: 1555032 kB
>>>>>> Inactive: 1634868 kB
>>>>>> Active(anon): 1527100 kB
>>>>>> Inactive(anon): 1607328 kB
>>>>>> Active(file): 27932 kB
>>>>>> Inactive(file): 27540 kB
>>>>>> Unevictable: 816 kB
>>>>>> Mlocked: 0 kB
>>>>>> SwapTotal: 6032344 kB
>>>>>> SwapFree: 4486496 kB
>>>>>> Dirty: 0 kB
>>>>>> Writeback: 0 kB
>>>>>> AnonPages: 2378112 kB
>>>>>> Mapped: 52196 kB
>>>>>> Slab: 65640 kB
>>>>>> SReclaimable: 46192 kB
>>>>>> SUnreclaim: 19448 kB
>>>>>> PageTables: 28200 kB
>>>>>> NFS_Unstable: 0 kB
>>>>>> Bounce: 0 kB
>>>>>> WritebackTmp: 0 kB
>>>>>> CommitLimit: 8055092 kB
>>>>>> Committed_AS: 4915636 kB
>>>>>> VmallocTotal: 34359738367 kB
>>>>>> VmallocUsed: 44580 kB
>>>>>> VmallocChunk: 34359677239 kB
>>>>>> DirectMap4k: 3182528 kB
>>>>>> DirectMap2M: 1011712 kB
>>>>>>
>>>>>> The cached reduced to 359 MB (after the dropping).
>>>>>> I dont know where to read the "number of mapped pages".
>>>>>> "Mapped" is about 51 MB.
>>>>> Does your tmpfs store lots of files?
>>>> Dont think so:
>>>>
>>>> # df -h
>>>> Filesystem Size Used Avail Use% Mounted on
>>>> /dev/md6 14G 8.2G 5.6G 60% /
>>>> udev 10M 304K 9.8M 3% /dev
>>>> cachedir 4.0M 100K 4.0M 3% /lib64/splash/cache
>>>> /dev/md4 19G 15G 3.1G 83% /home
>>>> /dev/md3 8.3G 4.5G 3.9G 55% /usr/portage
>>>> shm 2.0G 0 2.0G 0% /dev/shm
>>>> /dev/md1 99M 19M 76M 20% /boot
>>>>
>>>> # mount
>>>> /dev/md6 on / type ext3 (rw,noatime,nodiratime,barrier=0)
>>>> /proc on /proc type proc (rw,noexec,nosuid,noatime,nodiratime)
>>>> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
>>>> udev on /dev type tmpfs (rw,nosuid,size=10240k,mode=755)
>>>> devpts on /dev/pts type devpts (rw,nosuid,noexec,gid=5,mode=620)
>>>> cachedir on /lib64/splash/cache type tmpfs (rw,size=4096k,mode=644)
>>>> /dev/md4 on /home type ext3 (rw,noatime,nodiratime,barrier=0)
>>>> /dev/md3 on /usr/portage type ext4
> (rw,noatime,nodiratime,barrier=0)
>>>> shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
>>>> usbfs on /proc/bus/usb type usbfs
>>>> (rw,noexec,nosuid,devmode=0664,devgid=85)
>>>> automount(pid6507) on /mnt/.autofs/misc type autofs
>>>> (rw,fd=4,pgrp=6507,minproto=2,maxproto=4)
>>>> automount(pid6521) on /mnt/.autofs/usb type autofs
>>>> (rw,fd=4,pgrp=6521,minproto=2,maxproto=4)
>>>> /dev/md1 on /boot type ext2 (rw,noatime,nodiratime)
>>>>
>>>> I dont know what exactly all that memory is used for. It varies
> from
>>>> about 300 MB to up to one GB.
>>>> Tell me where to look and I will!
>>> So you don't have lots of mapped pages(Mapped=51M) or tmpfs files.
> It's
>>> strange to me that there are so many undroppable cached
> pages(Cached=359M),
>>> and most of them lie out of the LRU queue(Active+Inactive
> file=53M)...
>>> Anyone have better clues on these 'hidden' pages?
>> Maybe try this:
>>
>> cat /proc/`pidof X`/smaps | grep drm | wc -l
>>
>> you will see some growing numbers.
>>
>> Also check cat /proc/dri/0/gem_objects
>> there should be some number # object bytes - which should be close to
> your
>> missing cached pages.
>>
>>
>> If you are using Intel GEM driver - there is some unlimited caching
> issue
>> see: http://bugs.freedesktop.org/show_bug.cgi?id=20404
>>
> # cat /proc/`pidof X`/smaps | grep drm | wc -l
> 0
> # cat /proc/dri/0/gem_objects
> cat: /proc/dri/0/gem_objects: No such file or directory
>
> I use Xorg 1.3 with an nvidia gpu. Dont know if I use a "Intel GEM
> driver".
>
Are you using binary driver from NVidia ??
Maybe you should ask authors of this binary blob ?
Could you try to use for a while Vesa driver to see, if you are able to get
same strange results ?
Zdenek
WARNING: multiple messages have this Message-ID (diff)
From: Zdenek Kabelac <zkabelac@redhat.com>
To: Markus <M4rkusXXL@web.de>
Cc: linux-kernel@vger.kernel.org,
Wu Fengguang <fengguang.wu@intel.com>,
linux-mm@kvack.org
Subject: Re: drop_caches ...
Date: Wed, 04 Mar 2009 15:09:44 +0100 [thread overview]
Message-ID: <49AE8BA8.3080504@redhat.com> (raw)
In-Reply-To: <200903041447.49534.M4rkusXXL@web.de>
Markus napsal(a):
>>>>>>> The memory mapped pages won't be dropped in this way.
>>>>>>> "cat /proc/meminfo" will show you the number of mapped pages.
>>>>>> # sync ; echo 3 > /proc/sys/vm/drop_caches ; free -m ;
>>>> cat /proc/meminfo
>>>>>> total used free shared buffers
>>>>>> cached
>>>>>> Mem: 3950 3262 688 0 0
>>>>>> 359
>>>>>> -/+ buffers/cache: 2902 1047
>>>>>> Swap: 5890 1509 4381
>>>>>> MemTotal: 4045500 kB
>>>>>> MemFree: 705180 kB
>>>>>> Buffers: 508 kB
>>>>>> Cached: 367748 kB
>>>>>> SwapCached: 880744 kB
>>>>>> Active: 1555032 kB
>>>>>> Inactive: 1634868 kB
>>>>>> Active(anon): 1527100 kB
>>>>>> Inactive(anon): 1607328 kB
>>>>>> Active(file): 27932 kB
>>>>>> Inactive(file): 27540 kB
>>>>>> Unevictable: 816 kB
>>>>>> Mlocked: 0 kB
>>>>>> SwapTotal: 6032344 kB
>>>>>> SwapFree: 4486496 kB
>>>>>> Dirty: 0 kB
>>>>>> Writeback: 0 kB
>>>>>> AnonPages: 2378112 kB
>>>>>> Mapped: 52196 kB
>>>>>> Slab: 65640 kB
>>>>>> SReclaimable: 46192 kB
>>>>>> SUnreclaim: 19448 kB
>>>>>> PageTables: 28200 kB
>>>>>> NFS_Unstable: 0 kB
>>>>>> Bounce: 0 kB
>>>>>> WritebackTmp: 0 kB
>>>>>> CommitLimit: 8055092 kB
>>>>>> Committed_AS: 4915636 kB
>>>>>> VmallocTotal: 34359738367 kB
>>>>>> VmallocUsed: 44580 kB
>>>>>> VmallocChunk: 34359677239 kB
>>>>>> DirectMap4k: 3182528 kB
>>>>>> DirectMap2M: 1011712 kB
>>>>>>
>>>>>> The cached reduced to 359 MB (after the dropping).
>>>>>> I dont know where to read the "number of mapped pages".
>>>>>> "Mapped" is about 51 MB.
>>>>> Does your tmpfs store lots of files?
>>>> Dont think so:
>>>>
>>>> # df -h
>>>> Filesystem Size Used Avail Use% Mounted on
>>>> /dev/md6 14G 8.2G 5.6G 60% /
>>>> udev 10M 304K 9.8M 3% /dev
>>>> cachedir 4.0M 100K 4.0M 3% /lib64/splash/cache
>>>> /dev/md4 19G 15G 3.1G 83% /home
>>>> /dev/md3 8.3G 4.5G 3.9G 55% /usr/portage
>>>> shm 2.0G 0 2.0G 0% /dev/shm
>>>> /dev/md1 99M 19M 76M 20% /boot
>>>>
>>>> # mount
>>>> /dev/md6 on / type ext3 (rw,noatime,nodiratime,barrier=0)
>>>> /proc on /proc type proc (rw,noexec,nosuid,noatime,nodiratime)
>>>> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
>>>> udev on /dev type tmpfs (rw,nosuid,size=10240k,mode=755)
>>>> devpts on /dev/pts type devpts (rw,nosuid,noexec,gid=5,mode=620)
>>>> cachedir on /lib64/splash/cache type tmpfs (rw,size=4096k,mode=644)
>>>> /dev/md4 on /home type ext3 (rw,noatime,nodiratime,barrier=0)
>>>> /dev/md3 on /usr/portage type ext4
> (rw,noatime,nodiratime,barrier=0)
>>>> shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
>>>> usbfs on /proc/bus/usb type usbfs
>>>> (rw,noexec,nosuid,devmode=0664,devgid=85)
>>>> automount(pid6507) on /mnt/.autofs/misc type autofs
>>>> (rw,fd=4,pgrp=6507,minproto=2,maxproto=4)
>>>> automount(pid6521) on /mnt/.autofs/usb type autofs
>>>> (rw,fd=4,pgrp=6521,minproto=2,maxproto=4)
>>>> /dev/md1 on /boot type ext2 (rw,noatime,nodiratime)
>>>>
>>>> I dont know what exactly all that memory is used for. It varies
> from
>>>> about 300 MB to up to one GB.
>>>> Tell me where to look and I will!
>>> So you don't have lots of mapped pages(Mapped=51M) or tmpfs files.
> It's
>>> strange to me that there are so many undroppable cached
> pages(Cached=359M),
>>> and most of them lie out of the LRU queue(Active+Inactive
> file=53M)...
>>> Anyone have better clues on these 'hidden' pages?
>> Maybe try this:
>>
>> cat /proc/`pidof X`/smaps | grep drm | wc -l
>>
>> you will see some growing numbers.
>>
>> Also check cat /proc/dri/0/gem_objects
>> there should be some number # object bytes - which should be close to
> your
>> missing cached pages.
>>
>>
>> If you are using Intel GEM driver - there is some unlimited caching
> issue
>> see: http://bugs.freedesktop.org/show_bug.cgi?id=20404
>>
> # cat /proc/`pidof X`/smaps | grep drm | wc -l
> 0
> # cat /proc/dri/0/gem_objects
> cat: /proc/dri/0/gem_objects: No such file or directory
>
> I use Xorg 1.3 with an nvidia gpu. Dont know if I use a "Intel GEM
> driver".
>
Are you using binary driver from NVidia ??
Maybe you should ask authors of this binary blob ?
Could you try to use for a while Vesa driver to see, if you are able to get
same strange results ?
Zdenek
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-03-04 14:10 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-04 9:57 drop_caches Markus
2009-03-04 10:04 ` drop_caches Wu Fengguang
2009-03-04 10:32 ` drop_caches Markus
2009-03-04 11:05 ` drop_caches Wu Fengguang
2009-03-04 11:29 ` drop_caches Markus
2009-03-04 11:57 ` drop_caches Wu Fengguang
2009-03-04 11:57 ` drop_caches Wu Fengguang
2009-03-04 12:32 ` drop_caches Zdenek Kabelac
2009-03-04 12:32 ` drop_caches Zdenek Kabelac
2009-03-04 13:47 ` drop_caches Markus
2009-03-04 13:47 ` drop_caches Markus
2009-03-04 14:09 ` Zdenek Kabelac [this message]
2009-03-04 14:09 ` drop_caches Zdenek Kabelac
2009-03-04 18:47 ` drop_caches Markus
2009-03-04 18:47 ` drop_caches Markus
2009-03-05 0:48 ` drop_caches Wu Fengguang
2009-03-05 0:48 ` drop_caches Wu Fengguang
2009-03-05 9:06 ` drop_caches Lukas Hejtmanek
2009-03-05 9:06 ` drop_caches Lukas Hejtmanek
2009-03-05 9:14 ` drop_caches KOSAKI Motohiro
2009-03-05 9:14 ` drop_caches KOSAKI Motohiro
2009-03-05 11:11 ` drop_caches Wu Fengguang
2009-03-05 11:11 ` drop_caches Wu Fengguang
2009-03-05 11:55 ` drop_caches Markus
2009-03-05 11:55 ` drop_caches Markus
2009-03-05 13:29 ` drop_caches Wu Fengguang
2009-03-05 14:05 ` drop_caches Markus
2009-03-05 14:05 ` drop_caches Markus
2009-03-05 14:22 ` drop_caches Wu Fengguang
2009-03-05 14:22 ` drop_caches Wu Fengguang
2009-03-05 14:43 ` drop_caches Markus
2009-03-05 14:43 ` drop_caches Markus
2009-03-05 14:52 ` drop_caches Wu Fengguang
2009-03-05 14:52 ` drop_caches Wu Fengguang
2009-03-05 13:36 ` drop_caches Wu Fengguang
2009-03-05 13:36 ` drop_caches Wu Fengguang
2009-03-05 13:45 ` drop_caches Lukas Hejtmanek
2009-03-05 13:45 ` drop_caches Lukas Hejtmanek
2009-03-05 13:48 ` drop_caches Wu Fengguang
2009-03-05 13:48 ` drop_caches Wu Fengguang
2009-03-05 13:50 ` drop_caches Markus
2009-03-05 13:50 ` drop_caches Markus
2009-03-05 14:01 ` drop_caches Lukas Hejtmanek
2009-03-05 14:01 ` drop_caches Lukas Hejtmanek
2009-03-05 14:07 ` drop_caches Wu Fengguang
2009-03-05 14:07 ` drop_caches Wu Fengguang
-- strict thread matches above, loose matches on Subject: below --
2009-03-04 12:38 drop_caches Lukas Hejtmanek
2009-03-04 12:54 ` drop_caches Wu Fengguang
2009-03-04 12:54 ` drop_caches Wu Fengguang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49AE8BA8.3080504@redhat.com \
--to=zkabelac@redhat.com \
--cc=M4rkusXXL@web.de \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.