From: Pekka Enberg on
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
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
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
> 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
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/