[lustre-devel] AnonHugePages Virtual Memory Commit bug

[Prem Kumar]

Dear All,

Sorry to intervene and being rude and send this message directly to you
folks. I have made several attempts to reach to linux-kernel at vger.kernel.org
and my attempts have failed miserably and I have not be able make any
progress on this issue I have had for months now.

With all humbleness I request your help so that I can get assistance with
this issue of mine. Please guide me. I get hundreds-thousands of emails
from vger.kernel.org, not a problem, but I cannot post my question to the
email above. Any help will be like God's grace for me now.

My ISSUE:


I feel this is a bug. I am at kernel: 2.6.32-431.17.1.el6.x86_64

I have run into this many a times and only reboot has been the fix.

Issue is on every idle(not running any user processes) machine(diskless
node, & no swap) I see AnonHugePages limits the amount of memory that can
be allocated to any new process/program on that that system.

When ever I see this happen, atop always show vmcom > vmlim, i a situation
where there is no swap disk I am thinking this is causing the system to
lock up that memory from use by any other process on that system.

Any help here is appreciated.

Regards,
Prem

# cat /proc/meminfo
MemTotal:       24724728 kB
MemFree:         7062824 kB
Buffers:               0 kB
Cached:           656692 kB
SwapCached:            0 kB
Active:         16583276 kB
Inactive:         417380 kB
Active(anon):   16518316 kB
Inactive(anon):   251616 kB
Active(file):      64960 kB
Inactive(file):   165764 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:      16344124 kB
Mapped:            19316 kB
Shmem:            425968 kB
Slab:             127992 kB
SReclaimable:      22996 kB
SUnreclaim:       104996 kB
KernelStack:        2944 kB
PageTables:        56548 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    12362364 kB
Committed_AS:   17369952 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      493700 kB
VmallocChunk:   34346083172 kB
HardwareCorrupted:     0 kB
AnonHugePages:  16015360 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        7652 kB
DirectMap2M:    25145344 kB


On Mon, Nov 9, 2015 at 1:43 PM, kbuild test robot <lkp at intel.com> wrote:

> drivers/staging/lustre/lustre/llite/xattr.c:199:2-7: WARNING: NULL check
> before freeing functions like kfree, debugfs_remove,
> debugfs_remove_recursive or usb_free_urb is not needed. Maybe consider
> reorganizing relevant code to avoid passing NULL values.
>
>  NULL check before some freeing functions is not needed.
>
>  Based on checkpatch warning
>  "kfree(NULL) is safe this check is probably not required"
>  and kfreeaddr.cocci by Julia Lawall.
>
> Generated by: scripts/coccinelle/free/ifnullfree.cocci
>
> CC: Shivani Bhardwaj <shivanib134 at gmail.com>
> Signed-off-by: Fengguang Wu <fengguang.wu at intel.com>
> ---
>
>  xattr.c |    3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> --- a/drivers/staging/lustre/lustre/llite/xattr.c
> +++ b/drivers/staging/lustre/lustre/llite/xattr.c
> @@ -192,11 +192,10 @@ int ll_setxattr_common(struct inode *ino
>                          valid, name, pv, size, 0, flags,
>                          ll_i2suppgid(inode), &req);
>  #ifdef CONFIG_FS_POSIX_ACL
> -       if (new_value != NULL)
>                 /*
>                  * Release the posix ACL space.
>                  */
> -               kfree(new_value);
> +       kfree(new_value);
>         if (acl != NULL)
>                 lustre_ext_acl_xattr_free(acl);
>  #endif
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20151109/8ea762c2/attachment.htm>