Re: slub: Lockout validation scans during freeing of object

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2011.11.22 at 11:40 -0600, Christoph Lameter wrote:
> On Tue, 22 Nov 2011, Eric Dumazet wrote:
> 
> > This seems better, but I still have some warnings :
> 
> Trying to reproduce with a kernel configured to do preempt. This is
> actually quite interesting since its always off by 1.

BTW there are some obvious overflows in the "slabinfo -l" output on my machine:

Name                   Objects Objsize    Space Slabs/Part/Cpu  O/S O %Fr %Ef Flg
:t-0000024                 680      24    16.3K          0/0/4  170 0   0  99 *
:t-0000032                 768      32    24.5K          0/0/6  128 0   0 100 *
:t-0000040                1632      40    65.5K         13/0/3  102 0   0  99 *
:t-0000048                4533      48   241.6K 18446744073709551583/9/92   85 0  15  90 *
:t-0000064                3392      64   217.0K        30/0/23   64 0   0 100 *
:t-0000072                4368      72   319.4K         73/0/5   56 0   0  98 *
:t-0000112                 720     112    81.9K         0/0/20   36 0   0  98 *
:t-0000128                1684     128   233.4K 18446744073709551607/7/66   32 0  12  92 *
:t-0000136                 120     136    16.3K          0/0/4   30 0   0  99 *
:t-0000144                8036     144     1.1M        283/0/4   28 0   0  98 *
:t-0000192                4452     192   872.4K       165/0/48   21 0   0  97 *
:t-0000216                  90     216    20.4K          1/0/4   18 0   0  94 *
:t-0000256                 539     256   147.4K 18446744073709551609/3/43   16 0   8  93 *
:t-0000320                2425     320   794.6K         93/0/4   25 1   0  97 *A
:t-0000400                  60     400    24.5K          0/0/3   20 1   0  97 *
:t-0000512                 640     512   327.6K        23/0/17   16 1   0 100 *
:t-0000704                 483     704   344.0K         0/0/21   23 2   0  98 *A
:t-0001024                 373    1024   475.1K       15/10/14   16 2  34  80 *
:t-0002048                 288    2048   589.8K         10/0/8   16 3   0 100 *
:t-0004096                 119    4096   524.2K         4/3/12    8 3  18  92 *
Acpi-State                 204      80    16.3K          0/0/4   51 0   0  99 
anon_vma                  3528      64   258.0K         9/0/54   56 0   0  87 
bdev_cache                  84     728    65.5K          0/0/4   21 2   0  93 Aa
blkdev_queue                38    1664    65.5K          0/0/2   19 3   0  96 
blkdev_requests            161     344    57.3K          0/0/7   23 1   0  96 
buffer_head               1014     104   106.4K         5/0/21   39 0   0  99 a
cfq_queue                  102     232    24.5K          1/0/5   17 0   0  96 
dentry                   15897     192     3.1M       723/0/34   21 0   0  98 a
idr_layer_cache            390     544   212.9K          8/0/5   30 2   0  99 
inode_cache               6448     512     3.4M        199/0/9   31 2   0  96 a
ip_fib_trie                219      56    12.2K          0/0/3   73 0   0  99 
kmalloc-16                3072      16    49.1K          7/0/5  256 0   0 100 
kmalloc-8                 4608       8    36.8K          4/0/5  512 0   0 100 
kmalloc-8192                20    8192   163.8K          1/0/4    4 3   0 100 
kmalloc-96                 840      96    81.9K         7/0/13   42 0   0  98 
kmem_cache                  21     192     4.0K          0/0/1   21 0   0  98 *A
kmem_cache_node            192      64    12.2K          0/0/3   64 0   0 100 *A
mm_struct                  171     832   147.4K          0/0/9   19 2   0  96 A
mqueue_inode_cache          19     800    16.3K          0/0/1   19 2   0  92 A
nf_conntrack_ffffffff8199e380       60     264    16.3K          0/0/2   30 1   0  96 
proc_inode_cache           420     576   245.7K         2/0/13   28 2   0  98 a
radix_tree_node           3472     560     2.0M        120/0/4   28 2   0  95 a
RAW                         42     712    32.7K          0/0/2   21 2   0  91 A
shmem_inode_cache         1036     576   606.2K        21/0/16   28 2   0  98 
sighand_cache              210    2088   458.7K         3/0/11   15 3   0  95 A
signal_cache               268     920   360.4K 18446744073709551614/7/24   17 2  31  68 A
sigqueue                   125     160    20.4K          0/0/5   25 0   0  97 
skbuff_fclone_cache         72     420    32.7K          0/0/4   18 1   0  92 A
sock_inode_cache           196     560   114.6K          0/0/7   28 2   0  95 Aa
task_struct                215    1504   557.0K          9/9/8   21 3  52  58 
TCP                         21    1504    32.7K          0/0/1   21 3   0  96 A
UDP                         63     736    49.1K          0/0/3   21 2   0  94 A
vm_area_struct            3278     168   602.1K       89/33/58   24 0  22  91 
xfs_btree_cur               76     208    16.3K          0/0/4   19 0   0  96 
xfs_buf_item               108     224    24.5K          0/0/6   18 0   0  98 
xfs_da_state                64     488    32.7K          0/0/4   16 1   0  95 
xfs_inode                 7055     896     6.7M        411/0/4   17 2   0  92 Aa
xfs_log_ticket              80     200    16.3K          0/0/4   20 0   0  97 
xfs_trans                  116     280    32.7K          0/0/4   29 1   0  99 


-- 
Markus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  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@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]