Why task_struct slab can't be released back to buddy system?

DISCUSSION Zhang Zhen 2 participants 3 messages Apr 29, 2015 – Apr 30, 2015 Memory management

Share & tools

Zhang Zhen

author

2015-04-29 07:12 UTC #0 lore raw

Hi,

Our x86 system has crashed because oom.
We found task_struct slabs ate much memory.
And we analyzed the core file just as follows.

Why the page's inuse is 0 but the slab can't be released back to buddy system ? The memory allocator is slub.

crash> kmem -s task_struct
CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS SSIZE //**Slabs is much larger than alloctated object counts**
ffff88081e007500 task_struct 6528 4639 229775 45955 32k

crash> p *(struct kmem_cache *)0xffff88081e007500
$54 = {
cpu_slab = 0x14e10,
flags = 1074003968,
min_partial = 6,
size = 6528,
objsize = 6528,
offset = 0,
cpu_partial = 2,

  oo = {
    x = 196613
  },
  max = {
    x = 196613
  },
  min = {
    x = 65537
  },
  allocflags = 16384,
  refcount = 1,
  ctor = 0x0,
  inuse = 6528,
  align = 16,
  reserved = 0,
  name = 0xffff88081e000920 "task_struct",
  list = {
    next = 0xffff88081e007468,
    prev = 0xffff88081e007668
  },
  kobj = {
    name = 0xffff880810faf9b0 ":t-0006528",
    entry = {
      next = 0xffff88081e007480,
      prev = 0xffff88081e007680
    },
    parent = 0xffff880810fc0258,
    kset = 0xffff880810fc0240,
    ktype = 0xffffffff81847040 <slab_ktype>,
    sd = 0xffff880c2542c3f0,
    kref = {
      refcount = {
        counter = 1
      }
    },
    state_initialized = 1,
    state_in_sysfs = 1,
    state_add_uevent_sent = 1,
    state_remove_uevent_sent = 0,
    uevent_suppress = 0

},
remote_node_defrag_ratio = 1000,
node = {0xffff88081e001440, 0xffff880c2e800440, 0x0, 0x0, 0x0, 0x0,

crash> p *(struct kmem_cache_node *)0xffff88081e001440 $55 = {

  list_lock = {
    {
      rlock = {
        raw_lock = {
          {
            head_tail = 254283560,
            tickets = {
              head = 3880,
              tail = 3880
            }
          }
        }
      }
    }
  },
  nr_partial = 45287,
  partial = {
    next = 0xffffea0001396c20,
    prev = 0xffffea00202a8220
  },
  nr_slabs = {
    counter = 45829
  },
  total_objects = {
    counter = 229125
  },
  full = {
    next = 0xffff88081e001470,
    prev = 0xffff88081e001470

}
}

crash> p *((struct page *)((char *)0xffffea0001396c20-32)) $57 = {
flags = 9007199254757504,
mapping = 0x0,

  {
    {
      index = 18446612136879672448,
      freelist = 0xffff8801101f4c80
    },
    {
      counters = 4295294976,
      {
        {
          _mapcount = {
            counter = 327680
          },
          {
            inuse = 0,                         //##Here we found the slab page's inuse is 0.##
            objects = 5,
            frozen = 0
          }
        },
        _count = {
          counter = 1
        }
      }
    }
  },
  {
    lru = {
      next = 0xffffea00055dde20,
      prev = 0xffffea0002e0be20
    },
    {
      next = 0xffffea00055dde20,
      pages = 48283168,
      pobjects = -5632
    }
  },
  {
    private = 18446612167177303296,
    ptl = {
      {
        rlock = {
          raw_lock = {
            {
              head_tail = 503346432,
              tickets = {
                head = 29952,
                tail = 7680
              }
            }
          }
        }
      }
    },
    slab = 0xffff88081e007500,
    first_page = 0xffff88081e007500

}
}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Rasmus Villemoes

2015-04-29 10:58 UTC #1 lore raw

Quoted 4 lines · Zhang Zhen

Hi,
Our x86 system has crashed because oom.
We found task_struct slabs ate much memory.

I can't explain what you've seen, but a simple way to reduce the memory footprint of struct task_struct is

CONFIG_LATENCYTOP=n

That will reduce sizeof(struct task_struct) by ~3840 bytes (60%, give or take).

Rasmus

Quoted 2 lines

CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS SSIZE //**Slabs is much larger than alloctated object counts**
ffff88081e007500 task_struct 6528 4639 229775 45955 32k

Zhang Zhen

author

2015-04-30 01:44 UTC #2 lore raw

Quoted 7 lines · Rasmus Villemoes

Quoted 4 lines · Zhang Zhen
Hi,
Our x86 system has crashed because oom.
We found task_struct slabs ate much memory.

Quoted 8 lines

I can't explain what you've seen, but a simple way to reduce the memory footprint of struct task_struct is
CONFIG_LATENCYTOP=n
That will reduce sizeof(struct task_struct) by ~3840 bytes (60%, give or take).

Thank you for your sugesstion.

But my purpose is not to reduce sizeof(struct task_struct). I want to know why the task_struct slab can't be released back to buddy when the page's inuse is 0.

Best regards!

Quoted 6 lines

Rasmus
Quoted 2 lines
CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS SSIZE //**Slabs is much larger than alloctated object counts**
ffff88081e007500 task_struct 6528 4639 229775 45955 32k