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

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

[Zhang Zhen]

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

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

[Rasmus Villemoes]

On Wed, Apr 29 2015, Zhang Zhen <zhenzhang.zhang@huawei.com> wrote:

> 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

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

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

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

[Zhang Zhen]

On 2015/4/29 18:58, Rasmus Villemoes wrote:
> On Wed, Apr 29 2015, Zhang Zhen <zhenzhang.zhang@huawei.com> wrote:
> 
>> 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).
> 
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!
> Rasmus
> 
>> CACHE    	  NAME                 OBJSIZE  ALLOCATED     TOTAL  SLABS  SSIZE          //**Slabs is much larger than alloctated object counts**
>> ffff88081e007500 task_struct             6528       4639    229775  45955    32k
> 
> 


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