1. 05 9月, 2012 2 次提交
  2. 12 7月, 2012 1 次提交
  3. 09 7月, 2012 2 次提交
  4. 14 6月, 2012 4 次提交
  5. 31 10月, 2011 1 次提交
  6. 27 7月, 2011 1 次提交
  7. 08 6月, 2011 1 次提交
    • S
      slob/lockdep: Fix gfp flags passed to lockdep · bd50cfa8
      Steven Rostedt 提交于
      Doing a ktest.pl randconfig, I stumbled across the following bug
      on boot up:
      
      ------------[ cut here ]------------
      WARNING: at /home/rostedt/work/autotest/nobackup/linux-test.git/kernel/lockdep.c:2649 lockdep_trace_alloc+0xed/0x100()
      Hardware name:
      Modules linked in:
      Pid: 0, comm: swapper Not tainted 3.0.0-rc1-test-00054-g1d68b67 #1
      Call Trace:
       [<ffffffff810626ad>] warn_slowpath_common+0xad/0xf0
       [<ffffffff8106270a>] warn_slowpath_null+0x1a/0x20
       [<ffffffff810b537d>] lockdep_trace_alloc+0xed/0x100
       [<ffffffff81182fb0>] __kmalloc_node+0x30/0x2f0
       [<ffffffff81153eda>] pcpu_mem_alloc+0x13a/0x180
       [<ffffffff82be022c>] percpu_init_late+0x48/0xc2
       [<ffffffff82bd630c>] ? mem_init+0xd8/0xe3
       [<ffffffff82bbcc73>] start_kernel+0x1c2/0x449
       [<ffffffff82bbc35c>] x86_64_start_reservations+0x163/0x167
       [<ffffffff82bbc493>] x86_64_start_kernel+0x133/0x142^M
      ---[ end trace a7919e7f17c0a725 ]---
      
      Then I ran a ktest.pl config_bisect and it came up with this config
      as the problem:
      
        CONFIG_SLOB
      
      Looking at what is different between SLOB and SLAB and SLUB, I found
      that the gfp flags are masked against gfp_allowed_mask in
      SLAB and SLUB, but not SLOB.
      
      On boot up, interrupts are disabled and lockdep will warn if some flags
      are set in gfp and interrupts are disabled. But these flags are masked
      off with the gfp_allowed_mask during boot. Because SLOB does not
      mask the flags against gfp_allowed_mask it triggers the warn on.
      
      Adding this mask fixes the bug. I also found that kmem_cache_alloc_node()
      was missing both the mask and the lockdep check, and that was added too.
      Acked-by: NMatt Mackall <mpm@selenic.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NPekka Enberg <penberg@kernel.org>
      bd50cfa8
  8. 24 1月, 2011 1 次提交
  9. 07 1月, 2011 1 次提交
  10. 02 10月, 2010 1 次提交
  11. 16 7月, 2010 1 次提交
    • B
      SLOB: Free objects to their own list · d602daba
      Bob Liu 提交于
      SLOB has alloced smaller objects from their own list in reduce overall external
      fragmentation and increase repeatability, free to their own list also.
      
      This is /proc/meminfo result in my test machine:
      
        without this patch:
        ===
        MemTotal:        1030720 kB
        MemFree:          750012 kB
        Buffers:           15496 kB
        Cached:           160396 kB
        SwapCached:            0 kB
        Active:           105024 kB
        Inactive:         145604 kB
        Active(anon):      74816 kB
        Inactive(anon):     2180 kB
        Active(file):      30208 kB
        Inactive(file):   143424 kB
        Unevictable:          16 kB
        ....
      
        with this patch:
        ===
        MemTotal:        1030720 kB
        MemFree:          751908 kB
        Buffers:           15492 kB
        Cached:           160280 kB
        SwapCached:            0 kB
        Active:           102720 kB
        Inactive:         146140 kB
        Active(anon):      73168 kB
        Inactive(anon):     2180 kB
        Active(file):      29552 kB
        Inactive(file):   143960 kB
        Unevictable:          16 kB
        ...
      
      The result shows an improvement of 1 MB!
      
      And when I tested it on a embeded system with 64 MB, I found this path is never
      called during kernel bootup.
      Acked-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NBob Liu <lliubbo@gmail.com>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      d602daba
  12. 15 6月, 2010 1 次提交
  13. 09 6月, 2010 1 次提交
  14. 20 5月, 2010 1 次提交
  15. 06 8月, 2009 1 次提交
  16. 26 6月, 2009 1 次提交
  17. 17 6月, 2009 1 次提交
  18. 12 6月, 2009 1 次提交
  19. 11 5月, 2009 1 次提交
  20. 06 5月, 2009 1 次提交
  21. 12 4月, 2009 1 次提交
  22. 03 4月, 2009 2 次提交
  23. 31 3月, 2009 1 次提交
    • I
      lockdep: annotate reclaim context (__GFP_NOFS), fix SLOB · 19cefdff
      Ingo Molnar 提交于
      Impact: build fix
      
      fix typo in mm/slob.c:
      
       mm/slob.c:469: error: ‘flags’ undeclared (first use in this function)
       mm/slob.c:469: error: (Each undeclared identifier is reported only once
       mm/slob.c:469: error: for each function it appears in.)
      
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <20090128135457.350751756@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      19cefdff
  24. 23 3月, 2009 1 次提交
  25. 15 2月, 2009 1 次提交
    • N
      lockdep: annotate reclaim context (__GFP_NOFS) · cf40bd16
      Nick Piggin 提交于
      Here is another version, with the incremental patch rolled up, and
      added reclaim context annotation to kswapd, and allocation tracing
      to slab allocators (which may only ever reach the page allocator
      in rare cases, so it is good to put annotations here too).
      
      Haven't tested this version as such, but it should be getting closer
      to merge worthy ;)
      
      --
      After noticing some code in mm/filemap.c accidentally perform a __GFP_FS
      allocation when it should not have been, I thought it might be a good idea to
      try to catch this kind of thing with lockdep.
      
      I coded up a little idea that seems to work. Unfortunately the system has to
      actually be in __GFP_FS page reclaim, then take the lock, before it will mark
      it. But at least that might still be some orders of magnitude more common
      (and more debuggable) than an actual deadlock condition, so we have some
      improvement I hope (the concept is no less complete than discovery of a lock's
      interrupt contexts).
      
      I guess we could even do the same thing with __GFP_IO (normal reclaim), and
      even GFP_NOIO locks too... but filesystems will have the most locks and fiddly
      code paths, so let's start there and see how it goes.
      
      It *seems* to work. I did a quick test.
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.28-rc6-00007-ged313489-dirty #26
      ---------------------------------
      inconsistent {in-reclaim-W} -> {ov-reclaim-W} usage.
      modprobe/8526 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (testlock){--..}, at: [<ffffffffa0020055>] brd_init+0x55/0x216 [brd]
      {in-reclaim-W} state was registered at:
        [<ffffffff80267bdb>] __lock_acquire+0x75b/0x1a60
        [<ffffffff80268f71>] lock_acquire+0x91/0xc0
        [<ffffffff8070f0e1>] mutex_lock_nested+0xb1/0x310
        [<ffffffffa002002b>] brd_init+0x2b/0x216 [brd]
        [<ffffffff8020903b>] _stext+0x3b/0x170
        [<ffffffff80272ebf>] sys_init_module+0xaf/0x1e0
        [<ffffffff8020c3fb>] system_call_fastpath+0x16/0x1b
        [<ffffffffffffffff>] 0xffffffffffffffff
      irq event stamp: 3929
      hardirqs last  enabled at (3929): [<ffffffff8070f2b5>] mutex_lock_nested+0x285/0x310
      hardirqs last disabled at (3928): [<ffffffff8070f089>] mutex_lock_nested+0x59/0x310
      softirqs last  enabled at (3732): [<ffffffff8061f623>] sk_filter+0x83/0xe0
      softirqs last disabled at (3730): [<ffffffff8061f5b6>] sk_filter+0x16/0xe0
      
      other info that might help us debug this:
      1 lock held by modprobe/8526:
       #0:  (testlock){--..}, at: [<ffffffffa0020055>] brd_init+0x55/0x216 [brd]
      
      stack backtrace:
      Pid: 8526, comm: modprobe Not tainted 2.6.28-rc6-00007-ged313489-dirty #26
      Call Trace:
       [<ffffffff80265483>] print_usage_bug+0x193/0x1d0
       [<ffffffff80266530>] mark_lock+0xaf0/0xca0
       [<ffffffff80266735>] mark_held_locks+0x55/0xc0
       [<ffffffffa0020000>] ? brd_init+0x0/0x216 [brd]
       [<ffffffff802667ca>] trace_reclaim_fs+0x2a/0x60
       [<ffffffff80285005>] __alloc_pages_internal+0x475/0x580
       [<ffffffff8070f29e>] ? mutex_lock_nested+0x26e/0x310
       [<ffffffffa0020000>] ? brd_init+0x0/0x216 [brd]
       [<ffffffffa002006a>] brd_init+0x6a/0x216 [brd]
       [<ffffffffa0020000>] ? brd_init+0x0/0x216 [brd]
       [<ffffffff8020903b>] _stext+0x3b/0x170
       [<ffffffff8070f8b9>] ? mutex_unlock+0x9/0x10
       [<ffffffff8070f83d>] ? __mutex_unlock_slowpath+0x10d/0x180
       [<ffffffff802669ec>] ? trace_hardirqs_on_caller+0x12c/0x190
       [<ffffffff80272ebf>] sys_init_module+0xaf/0x1e0
       [<ffffffff8020c3fb>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cf40bd16
  26. 12 2月, 2009 1 次提交
  27. 19 1月, 2009 1 次提交
  28. 30 12月, 2008 1 次提交
    • F
      tracing/kmemtrace: normalize the raw tracer event to the unified tracing API · 36994e58
      Frederic Weisbecker 提交于
      Impact: new tracer plugin
      
      This patch adapts kmemtrace raw events tracing to the unified tracing API.
      
      To enable and use this tracer, just do the following:
      
       echo kmemtrace > /debugfs/tracing/current_tracer
       cat /debugfs/tracing/trace
      
      You will have the following output:
      
       # tracer: kmemtrace
       #
       #
       # ALLOC  TYPE  REQ   GIVEN  FLAGS           POINTER         NODE    CALLER
       # FREE   |      |     |       |              |   |            |        |
       # |
      
      type_id 1 call_site 18446744071565527833 ptr 18446612134395152256
      type_id 0 call_site 18446744071565585597 ptr 18446612134405955584 bytes_req 4096 bytes_alloc 4096 gfp_flags 208 node -1
      type_id 1 call_site 18446744071565585534 ptr 18446612134405955584
      type_id 0 call_site 18446744071565585597 ptr 18446612134405955584 bytes_req 4096 bytes_alloc 4096 gfp_flags 208 node -1
      type_id 0 call_site 18446744071565636711 ptr 18446612134345164672 bytes_req 240 bytes_alloc 240 gfp_flags 208 node -1
      type_id 1 call_site 18446744071565585534 ptr 18446612134405955584
      type_id 0 call_site 18446744071565585597 ptr 18446612134405955584 bytes_req 4096 bytes_alloc 4096 gfp_flags 208 node -1
      type_id 0 call_site 18446744071565636711 ptr 18446612134345164912 bytes_req 240 bytes_alloc 240 gfp_flags 208 node -1
      type_id 1 call_site 18446744071565585534 ptr 18446612134405955584
      type_id 0 call_site 18446744071565585597 ptr 18446612134405955584 bytes_req 4096 bytes_alloc 4096 gfp_flags 208 node -1
      type_id 0 call_site 18446744071565636711 ptr 18446612134345165152 bytes_req 240 bytes_alloc 240 gfp_flags 208 node -1
      type_id 0 call_site 18446744071566144042 ptr 18446612134346191680 bytes_req 1304 bytes_alloc 1312 gfp_flags 208 node -1
      type_id 1 call_site 18446744071565585534 ptr 18446612134405955584
      type_id 0 call_site 18446744071565585597 ptr 18446612134405955584 bytes_req 4096 bytes_alloc 4096 gfp_flags 208 node -1
      type_id 1 call_site 18446744071565585534 ptr 18446612134405955584
      
      That was to stay backward compatible with the format output produced in
      inux/tracepoint.h.
      
      This is the default ouput, but note that I tried something else.
      
      If you change an option:
      
      echo kmem_minimalistic > /debugfs/trace_options
      
      and then cat /debugfs/trace, you will have the following output:
      
       # tracer: kmemtrace
       #
       #
       # ALLOC  TYPE  REQ   GIVEN  FLAGS           POINTER         NODE    CALLER
       # FREE   |      |     |       |              |   |            |        |
       # |
      
         -      C                            0xffff88007c088780          file_free_rcu
         +      K   4096   4096   000000d0   0xffff88007cad6000     -1   getname
         -      C                            0xffff88007cad6000          putname
         +      K   4096   4096   000000d0   0xffff88007cad6000     -1   getname
         +      K    240    240   000000d0   0xffff8800790dc780     -1   d_alloc
         -      C                            0xffff88007cad6000          putname
         +      K   4096   4096   000000d0   0xffff88007cad6000     -1   getname
         +      K    240    240   000000d0   0xffff8800790dc870     -1   d_alloc
         -      C                            0xffff88007cad6000          putname
         +      K   4096   4096   000000d0   0xffff88007cad6000     -1   getname
         +      K    240    240   000000d0   0xffff8800790dc960     -1   d_alloc
         +      K   1304   1312   000000d0   0xffff8800791d7340     -1   reiserfs_alloc_inode
         -      C                            0xffff88007cad6000          putname
         +      K   4096   4096   000000d0   0xffff88007cad6000     -1   getname
         -      C                            0xffff88007cad6000          putname
         +      K    992   1000   000000d0   0xffff880079045b58     -1   alloc_inode
         +      K    768   1024   000080d0   0xffff88007c096400     -1   alloc_pipe_info
         +      K    240    240   000000d0   0xffff8800790dca50     -1   d_alloc
         +      K    272    320   000080d0   0xffff88007c088780     -1   get_empty_filp
         +      K    272    320   000080d0   0xffff88007c088000     -1   get_empty_filp
      
      Yeah I shall confess kmem_minimalistic should be: kmem_alternative.
      
      Whatever, I find it more readable but this a personal opinion of course.
      We can drop it if you want.
      
      On the ALLOC/FREE column, + means an allocation and - a free.
      
      On the type column, you have K = kmalloc, C = cache, P = page
      
      I would like the flags to be GFP_* strings but that would not be easy to not
      break the column with strings....
      
      About the node...it seems to always be -1. I don't know why but that shouldn't
      be difficult to find.
      
      I moved linux/tracepoint.h to trace/tracepoint.h as well. I think that would
      be more easy to find the tracer headers if they are all in their common
      directory.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      36994e58
  29. 29 12月, 2008 1 次提交
  30. 16 12月, 2008 1 次提交
  31. 10 10月, 2008 1 次提交
  32. 08 10月, 2008 1 次提交
  33. 30 7月, 2008 1 次提交
  34. 27 7月, 2008 1 次提交