Prev: [PATCH net-next] drivers/net/bfin_mac.c: Use pr_fmt, netdev_<level>
Next: [PATCH] vmscan: remove wait_on_page_writeback() from pageout()
From: Pekka Enberg on 31 Jul 2010 14:00 On Sat, Jul 31, 2010 at 8:33 PM, Christoph Hellwig <hch(a)infradead.org> wrote: > On Sun, Aug 01, 2010 at 12:13:58AM +0800, Wu Fengguang wrote: >> FYI I did some memory stress test and find there are much more order-1 >> (and higher) users than fork(). This means lots of running applications >> may stall on direct reclaim. >> >> Basically all of these slab caches will do high order allocations: > > It looks much, much worse on my system. �Basically all inode structures, > and also tons of frequently allocated xfs structures fall into this > category, �None of them actually anywhere near the size of a page, which > makes me wonder why we do such high order allocations: Do you have CONFIG_SLUB enabled? It does high order allocations by default for performance reasons. > slabinfo - version: 2.1 > # name � � � � � �<active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail> > nfsd4_stateowners � � �0 � � �0 � �424 � 19 � �2 : tunables � �0 � �0 � �0 : slabdata � � �0 � � �0 � � �0 > kvm_vcpu � � � � � � � 0 � � �0 �10400 � �3 � �8 : tunables � �0 � �0 � �0 : slabdata � � �0 � � �0 � � �0 > kmalloc_dma-512 � � � 32 � � 32 � �512 � 16 � �2 : tunables � �0 � �0 � �0 : slabdata � � �2 � � �2 � � �0 > mqueue_inode_cache � � 18 � � 18 � �896 � 18 � �4 : tunables � �0 � �0 � �0 : slabdata � � �1 � � �1 � � �0 > xfs_inode � � � � 279008 279008 � 1024 � 16 � �4 : tunables � �0 � �0 � �0 : slabdata �17438 �17438 � � �0 > xfs_efi_item � � � � �44 � � 44 � �360 � 22 � �2 : tunables � �0 � �0 � �0 : slabdata � � �2 � � �2 � � �0 > xfs_efd_item � � � � �44 � � 44 � �368 � 22 � �2 : tunables � �0 � �0 � �0 : slabdata � � �2 � � �2 � � �0 > xfs_trans � � � � � � 40 � � 40 � �800 � 20 � �4 : tunables � �0 � �0 � �0 : slabdata � � �2 � � �2 � � �0 > xfs_da_state � � � � �32 � � 32 � �488 � 16 � �2 : tunables � �0 � �0 � �0 : slabdata � � �2 � � �2 � � �0 > nfs_inode_cache � � � �0 � � �0 � 1016 � 16 � �4 : tunables � �0 � �0 � �0 : slabdata � � �0 � � �0 � � �0 > isofs_inode_cache � � �0 � � �0 � �632 � 25 � �4 : tunables � �0 � �0 � �0 : slabdata � � �0 � � �0 � � �0 > fat_inode_cache � � � �0 � � �0 � �664 � 12 � �2 : tunables � �0 � �0 � �0 : slabdata � � �0 � � �0 � � �0 > hugetlbfs_inode_cache � � 14 � � 14 � �584 � 14 � �2 : tunables � �0 � �0 � �0 : slabdata � � �1 � � �1 � � �0 > ext4_inode_cache � � � 0 � � �0 � �968 � 16 � �4 : tunables � �0 � �0 � �0 : slabdata � � �0 � � �0 � � �0 > ext2_inode_cache � � �21 � � 21 � �776 � 21 � �4 : tunables � �0 � �0 � �0 : slabdata � � �1 � � �1 � � �0 > ext3_inode_cache � � � 0 � � �0 � �800 � 20 � �4 : tunables � �0 � �0 � �0 : slabdata � � �0 � � �0 � � �0 > rpc_inode_cache � � � 19 � � 19 � �832 � 19 � �4 : tunables � �0 � �0 � �0 : slabdata � � �1 � � �1 � � �0 > UDP-Lite � � � � � � � 0 � � �0 � �768 � 21 � �4 : tunables � �0 � �0 � �0 : slabdata � � �0 � � �0 � � �0 > ip_dst_cache � � � � 170 � �378 � �384 � 21 � �2 : tunables � �0 � �0 � �0 : slabdata � � 18 � � 18 � � �0 > RAW � � � � � � � � � 63 � � 63 � �768 � 21 � �4 : tunables � �0 � �0 � �0 : slabdata � � �3 � � �3 � � �0 > UDP � � � � � � � � � 52 � � 84 � �768 � 21 � �4 : tunables � �0 � �0 � �0 : slabdata � � �4 � � �4 � � �0 > TCP � � � � � � � � � 60 � �100 � 1600 � 20 � �8 : tunables � �0 � �0 � �0 : slabdata � � �5 � � �5 � � �0 > blkdev_queue � � � � �42 � � 42 � 2216 � 14 � �8 : tunables � �0 � �0 � �0 : slabdata � � �3 � � �3 � � �0 > sock_inode_cache � � 650 � �713 � �704 � 23 � �4 : tunables � �0 � �0 � �0 : slabdata � � 31 � � 31 � � �0 > skbuff_fclone_cache � � 36 � � 36 � �448 � 18 � �2 : tunables � �0 � �0 � �0 : slabdata � � �2 � � �2 � � �0 > shmem_inode_cache � 3620 � 3948 � �776 � 21 � �4 : tunables � �0 � �0 � �0 : slabdata � �188 � �188 � � �0 > proc_inode_cache � �1818 � 1875 � �632 � 25 � �4 : tunables � �0 � �0 � �0 : slabdata � � 75 � � 75 � � �0 > bdev_cache � � � � � �57 � � 57 � �832 � 19 � �4 : tunables � �0 � �0 � �0 : slabdata � � �3 � � �3 � � �0 > inode_cache � � � � 7934 � 7938 � �584 � 14 � �2 : tunables � �0 � �0 � �0 : slabdata � �567 � �567 � � �0 > files_cache � � � � �689 � �713 � �704 � 23 � �4 : tunables � �0 � �0 � �0 : slabdata � � 31 � � 31 � � �0 > signal_cache � � � � 301 � �342 � �896 � 18 � �4 : tunables � �0 � �0 � �0 : slabdata � � 19 � � 19 � � �0 > sighand_cache � � � �192 � �210 � 2112 � 15 � �8 : tunables � �0 � �0 � �0 : slabdata � � 14 � � 14 � � �0 > task_struct � � � � �311 � �325 � 5616 � �5 � �8 : tunables � �0 � �0 � �0 : slabdata � � 65 � � 65 � � �0 > idr_layer_cache � � �578 � �585 � �544 � 15 � �2 : tunables � �0 � �0 � �0 : slabdata � � 39 � � 39 � � �0 > radix_tree_node � �74738 �74802 � �560 � 14 � �2 : tunables � �0 � �0 � �0 : slabdata � 5343 � 5343 � � �0 > kmalloc-8192 � � � � �29 � � 32 � 8192 � �4 � �8 : tunables � �0 � �0 � �0 : slabdata � � �8 � � �8 � � �0 > kmalloc-4096 � � � � 194 � �208 � 4096 � �8 � �8 : tunables � �0 � �0 � �0 : slabdata � � 26 � � 26 � � �0 > kmalloc-2048 � � � � 310 � �352 � 2048 � 16 � �8 : tunables � �0 � �0 � �0 : slabdata � � 22 � � 22 � � �0 > kmalloc-1024 � � � �1607 � 1616 � 1024 � 16 � �4 : tunables � �0 � �0 � �0 : slabdata � �101 � �101 � � �0 > kmalloc-512 � � � � �484 � �512 � �512 � 16 � �2 : tunables � �0 � �0 � �0 : slabdata � � 32 � � 32 � � �0 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo(a)kvack.org. �For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont(a)kvack.org"> email(a)kvack.org </a> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 31 Jul 2010 14:10 On Sat, Jul 31, 2010 at 8:59 PM, Christoph Hellwig <hch(a)infradead.org> wrote: > On Sat, Jul 31, 2010 at 08:55:57PM +0300, Pekka Enberg wrote: >> Do you have CONFIG_SLUB enabled? It does high order allocations by >> default for performance reasons. > > Yes. This is a kernel using slub. You can pass "slub_debug=o" as a kernel parameter to disable higher order allocations if you want to test things. The per-cache default order is calculated in calculate_order() of mm/slub.c. How many CPUs do you have on your system? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 31 Jul 2010 14:10 On Sat, Jul 31, 2010 at 08:55:57PM +0300, Pekka Enberg wrote: > Do you have CONFIG_SLUB enabled? It does high order allocations by > default for performance reasons. Yes. This is a kernel using slub. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on 1 Aug 2010 05:00 > Reported-by: Andreas Mohr <andi(a)lisas.de> > Reviewed-by: Minchan Kim <minchan.kim(a)gmail.com> > Signed-off-by: Mel Gorman <mel(a)csn.ul.ie> > Signed-off-by: Wu Fengguang <fengguang.wu(a)intel.com> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mel Gorman on 5 Aug 2010 11:10
On Thu, Aug 05, 2010 at 03:12:22PM +0900, KOSAKI Motohiro wrote: > From: Wu Fengguang <fengguang.wu(a)intel.com> > > Fix "system goes unresponsive under memory pressure and lots of > dirty/writeback pages" bug. > > http://lkml.org/lkml/2010/4/4/86 > > In the above thread, Andreas Mohr described that > > Invoking any command locked up for minutes (note that I'm > talking about attempted additional I/O to the _other_, > _unaffected_ main system HDD - such as loading some shell > binaries -, NOT the external SSD18M!!). > > This happens when the two conditions are both meet: > - under memory pressure > - writing heavily to a slow device > > <SNIP> Other than an unnecessary whitespace removal at the end of the patch, I see no problem with letting this patch stand on it's own as we are reasonably sure this patch fixes a problem on its own. Patches 2-7 might further improve the situation but can be considered as a new series. This patch (as well as most of the series) will reject against current mmotm because of other reclaim-related patches already in there. The resolutions are not too hard but bear it in mind. > <SNIP> -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |