[Bug 111875] [CI][SHARDS]igt at gem_exec_reuse@contexts - incomplete - Out of memory

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Oct 1 12:53:05 UTC 2019


https://bugs.freedesktop.org/show_bug.cgi?id=111875

--- Comment #3 from Chris Wilson <chris at chris-wilson.co.uk> ---
ickle at broadwell:~/linux$ git bisect bad
c5665868183fec689dbab9fb8505188b2c4f0757 is the first bad commit
commit c5665868183fec689dbab9fb8505188b2c4f0757
Author: Catalin Marinas <catalin.marinas at arm.com>
Date:   Mon Sep 23 15:34:05 2019 -0700

    mm: kmemleak: use the memory pool for early allocations

    Currently kmemleak uses a static early_log buffer to trace all memory
    allocation/freeing before the slab allocator is initialised.  Such early
    log is replayed during kmemleak_init() to properly initialise the kmemleak
    metadata for objects allocated up that point.  With a memory pool that
    does not rely on the slab allocator, it is possible to skip this early log
    entirely.

    In order to remove the early logging, consider kmemleak_enabled == 1 by
    default while the kmem_cache availability is checked directly on the
    object_cache and scan_area_cache variables.  The RCU callback is only
    invoked after object_cache has been initialised as we wouldn't have any
    concurrent list traversal before this.

    In order to reduce the number of callbacks before kmemleak is fully
    initialised, move the kmemleak_init() call to mm_init().

    [akpm at linux-foundation.org: coding-style fixes]
    [akpm at linux-foundation.org: remove WARN_ON(), per Catalin]
    Link:
http://lkml.kernel.org/r/20190812160642.52134-4-catalin.marinas@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
    Cc: Matthew Wilcox <willy at infradead.org>
    Cc: Michal Hocko <mhocko at kernel.org>
    Cc: Qian Cai <cai at lca.pw>
    Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20191001/fbb62a3d/attachment.html>


More information about the intel-gfx-bugs mailing list