On 9/30/17 11:43 PM, Christopher Lameter wrote:

On Thu, 28 Sep 2017, Yang Shi wrote:

CONFIG_SLABINFO and /proc/slabinfo have nothing to do with the
unreclaimable slab info.

The current design uses "struct slabinfo" and get_slabinfo() to retrieve some
info, i.e. active objs, etc. They are protected by CONFIG_SLABINFO.

Ok I guess then those need to be moved out of CONFIG_SLABINFO. Otherwise dumping of slabs will not be supported when disabling that option.

Yes.

Or dump CONFIG_SLABINFO ..

I prefer to this. It sounds pointless to keep CONFIG_SLABINFO. It is
always on by default and can't be changed in menuconfig.

Thanks,
Yang



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/2/17 12:26 AM, Michal Hocko wrote:

On Thu 28-09-17 01:25:50, Yang Shi wrote:

On 9/27/17 3:45 AM, Michal Hocko wrote:

On Wed 27-09-17 08:53:35, Yang Shi wrote:

Kernel may panic when oom happens without killable process sometimes it >>>> is caused by huge unreclaimable slabs used by kernel.

Although kdump could help debug such problem, however, kdump is not
available on all architectures and it might be malfunction sometime.
And, since kernel already panic it is worthy capturing such information >>>> in dmesg to aid touble shooting.

Print out unreclaimable slab info (used size and total size) which
actual memory usage is not zero (num_objs * size != 0) when:
- unreclaimable slabs : all user memory > unreclaim_slabs_oom_ratio >>>> - panic_on_oom is set or no killable process

OK, this is better but I do not see why this should be tunable via proc.

Just thought someone might want to dump unreclaimable slab info
unconditionally.

If that ever happens then we will eventually add it. But do not add proc knobs for theoretical usecases. We will have to maintain them and it
can turn into a maint. pain. Like some others in the past.

It has been removed since v8. Currently the only condition is
unreclaimable slabs > user memory.

Thanks,
Yang



--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)