From: Jiri Slaby <jslaby@suse.cz>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Too much free memory (not used for FS cache)
Date: Thu, 15 Mar 2012 21:15:41 +0100 [thread overview]
Message-ID: <4F624DED.2060302@suse.cz> (raw)
In-Reply-To: <4F624C88.6050503@suse.cz>
On 03/15/2012 09:09 PM, Jiri Slaby wrote:
> Hi,
>
> since today's -next (20120315), the MM/VFS system is very sluggish.
> Especially when committing, diffing and similar with git. I still have
> 2G of 6G of memory free. But with each commit I have to wait for git to
> fetch all data from disk.
>
> I'm using ext4 on a raid for the partition with git kernel repository if
> that matters.
>
> Any idea what that could be?
Please ignore this. It's not as easy as that. It doesn't wait for IO and
needs more investigation...
> nr_free_pages 555469
> nr_inactive_anon 16787
> nr_active_anon 414439
> nr_inactive_file 315585
> nr_active_file 137446
> nr_unevictable 0
> nr_mlock 0
> nr_anon_pages 277729
> nr_mapped 95971
> nr_file_pages 524644
> nr_dirty 11
> nr_writeback 0
> nr_slab_reclaimable 35548
> nr_slab_unreclaimable 7450
> nr_page_table_pages 11493
> nr_kernel_stack 464
> nr_unstable 0
> nr_bounce 0
> nr_vmscan_write 0
> nr_vmscan_immediate_reclaim 0
> nr_writeback_temp 0
> nr_isolated_anon 0
> nr_isolated_file 0
> nr_shmem 71614
> nr_dirtied 1165398
> nr_written 1147058
> nr_anon_transparent_hugepages 160
> nr_dirty_threshold 97608
> nr_dirty_background_threshold 48804
> pgpgin 2446144
> pgpgout 4844237
> pswpin 0
> pswpout 0
> pgalloc_dma 0
> pgalloc_dma32 21764611
> pgalloc_normal 38307626
> pgalloc_movable 0
> pgfree 60640227
> pgactivate 913299
> pgdeactivate 109336
> pgfault 51012433
> pgmajfault 8476
> pgrefill_dma 0
> pgrefill_dma32 79208
> pgrefill_normal 41244
> pgrefill_movable 0
> pgsteal_dma 0
> pgsteal_dma32 162966
> pgsteal_normal 185373
> pgsteal_movable 0
> pgscan_kswapd_dma 0
> pgscan_kswapd_dma32 162559
> pgscan_kswapd_normal 215360
> pgscan_kswapd_movable 0
> pgscan_direct_dma 0
> pgscan_direct_dma32 1624
> pgscan_direct_normal 3927
> pgscan_direct_movable 0
> pginodesteal 4
> slabs_scanned 102400
> kswapd_steal 342881
> kswapd_inodesteal 756
> kswapd_low_wmark_hit_quickly 0
> kswapd_high_wmark_hit_quickly 119
> kswapd_skip_congestion_wait 0
> pageoutrun 3493
> allocstall 5
> pgrotated 240
> compact_blocks_moved 432
> compact_pages_moved 10699
> compact_pagemigrate_failed 0
> compact_stall 14
> compact_fail 5
> compact_success 9
> htlb_buddy_alloc_success 0
> htlb_buddy_alloc_fail 0
> unevictable_pgs_culled 327
> unevictable_pgs_scanned 0
> unevictable_pgs_rescued 2618
> unevictable_pgs_mlocked 2618
> unevictable_pgs_munlocked 2618
> unevictable_pgs_cleared 0
> unevictable_pgs_stranded 0
> unevictable_pgs_mlockfreed 0
> thp_fault_alloc 13147
> thp_fault_fallback 0
> thp_collapse_alloc 3543
> thp_collapse_alloc_failed 0
> thp_split 183
>
> thanks,
--
js
suse labs
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Slaby <jslaby@suse.cz>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Too much free memory (not used for FS cache)
Date: Thu, 15 Mar 2012 21:15:41 +0100 [thread overview]
Message-ID: <4F624DED.2060302@suse.cz> (raw)
In-Reply-To: <4F624C88.6050503@suse.cz>
On 03/15/2012 09:09 PM, Jiri Slaby wrote:
> Hi,
>
> since today's -next (20120315), the MM/VFS system is very sluggish.
> Especially when committing, diffing and similar with git. I still have
> 2G of 6G of memory free. But with each commit I have to wait for git to
> fetch all data from disk.
>
> I'm using ext4 on a raid for the partition with git kernel repository if
> that matters.
>
> Any idea what that could be?
Please ignore this. It's not as easy as that. It doesn't wait for IO and
needs more investigation...
> nr_free_pages 555469
> nr_inactive_anon 16787
> nr_active_anon 414439
> nr_inactive_file 315585
> nr_active_file 137446
> nr_unevictable 0
> nr_mlock 0
> nr_anon_pages 277729
> nr_mapped 95971
> nr_file_pages 524644
> nr_dirty 11
> nr_writeback 0
> nr_slab_reclaimable 35548
> nr_slab_unreclaimable 7450
> nr_page_table_pages 11493
> nr_kernel_stack 464
> nr_unstable 0
> nr_bounce 0
> nr_vmscan_write 0
> nr_vmscan_immediate_reclaim 0
> nr_writeback_temp 0
> nr_isolated_anon 0
> nr_isolated_file 0
> nr_shmem 71614
> nr_dirtied 1165398
> nr_written 1147058
> nr_anon_transparent_hugepages 160
> nr_dirty_threshold 97608
> nr_dirty_background_threshold 48804
> pgpgin 2446144
> pgpgout 4844237
> pswpin 0
> pswpout 0
> pgalloc_dma 0
> pgalloc_dma32 21764611
> pgalloc_normal 38307626
> pgalloc_movable 0
> pgfree 60640227
> pgactivate 913299
> pgdeactivate 109336
> pgfault 51012433
> pgmajfault 8476
> pgrefill_dma 0
> pgrefill_dma32 79208
> pgrefill_normal 41244
> pgrefill_movable 0
> pgsteal_dma 0
> pgsteal_dma32 162966
> pgsteal_normal 185373
> pgsteal_movable 0
> pgscan_kswapd_dma 0
> pgscan_kswapd_dma32 162559
> pgscan_kswapd_normal 215360
> pgscan_kswapd_movable 0
> pgscan_direct_dma 0
> pgscan_direct_dma32 1624
> pgscan_direct_normal 3927
> pgscan_direct_movable 0
> pginodesteal 4
> slabs_scanned 102400
> kswapd_steal 342881
> kswapd_inodesteal 756
> kswapd_low_wmark_hit_quickly 0
> kswapd_high_wmark_hit_quickly 119
> kswapd_skip_congestion_wait 0
> pageoutrun 3493
> allocstall 5
> pgrotated 240
> compact_blocks_moved 432
> compact_pages_moved 10699
> compact_pagemigrate_failed 0
> compact_stall 14
> compact_fail 5
> compact_success 9
> htlb_buddy_alloc_success 0
> htlb_buddy_alloc_fail 0
> unevictable_pgs_culled 327
> unevictable_pgs_scanned 0
> unevictable_pgs_rescued 2618
> unevictable_pgs_mlocked 2618
> unevictable_pgs_munlocked 2618
> unevictable_pgs_cleared 0
> unevictable_pgs_stranded 0
> unevictable_pgs_mlockfreed 0
> thp_fault_alloc 13147
> thp_fault_fallback 0
> thp_collapse_alloc 3543
> thp_collapse_alloc_failed 0
> thp_split 183
>
> thanks,
--
js
suse labs
next prev parent reply other threads:[~2012-03-15 20:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-15 20:09 Too much free memory (not used for FS cache) Jiri Slaby
2012-03-15 20:15 ` Jiri Slaby [this message]
2012-03-15 20:15 ` Jiri Slaby
2012-03-15 20:19 ` Andrew Morton
2012-03-15 20:19 ` Andrew Morton
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=4F624DED.2060302@suse.cz \
--to=jslaby@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=jirislaby@gmail.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.