| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <AANLkTi=+muw_2jWq1QKsxp6A_fAtdhdns7MD_bKQo-72@mail.gmail.com> Date: Sat, 31 Jul 2010 20:55:57 +0300 From: Pekka Enberg <penberg@...helsinki.fi> To: Christoph Hellwig <hch@...radead.org> Cc: Wu Fengguang <fengguang.wu@...el.com>, Andrew Morton <akpm@...ux-foundation.org>, stable@...nel.org, Rik van Riel <riel@...hat.com>, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, Mel Gorman <mel@....ul.ie>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, Dave Chinner <david@...morbit.com>, Chris Mason <chris.mason@...cle.com>, Nick Piggin <npiggin@...e.de>, Johannes Weiner <hannes@...xchg.org>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, Andrea Arcangeli <aarcange@...hat.com>, Minchan Kim <minchan.kim@...il.com>, Andreas Mohr <andi@...as.de>, Bill Davidsen <davidsen@....com>, Ben Gamari <bgamari.foss@...il.com>, Christoph Lameter <cl@...ux-foundation.org> Subject: Re: [PATCH] vmscan: raise the bar to PAGEOUT_IO_SYNC stalls On Sat, Jul 31, 2010 at 8:33 PM, Christoph Hellwig <hch@...radead.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@...ck.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists