All of lore.kernel.org
 help / color / mirror / Atom feed
From: xtu4 <xiaobing.tu@intel.com>
To: linux-kernel@vger.kernel.org, guifang.tang@intel.com,
	linX.z.chen@intel.com, akpm@linux-foundation.org,
	yanmin.zhang@intel.com
Subject: Re: resend----[PATCH] Avoid high order memory allocating with kmalloc, when read large seq file
Date: Fri, 01 Feb 2013 11:31:12 +0800	[thread overview]
Message-ID: <510B3700.5070602@intel.com> (raw)
In-Reply-To: <510A0B14.70800@intel.com>

On 01/31/2013 02:11 PM, xtu4 wrote:
> [SEQ_FILE] Avoid high order memory allocating with kmalloc
>  when read large seq file
>
> currently, when dumpstate access /proc/xxx/binder , this binder 
> include lots of info,
> it will use seq_read in kernel, in this function, it will trigger high 
> order memory alloc,
> when read binder info or other large file, this will cause memory 
> presure when system
> don't have contious high order memory, it will lead to high kswap 
> workload to reclaim the
> page. so change kmalloc to vmalloc, it can avoid contiously high order 
> memory allocating.
> [ 4356.532357] dumpstate: page allocation failure: order:4, mode:0x40d0
> [ 4356.532400] Pid: 18256, comm: dumpstate Tainted: G         C 
> 3.0.34-141128-g4be7088 #1
> [ 4356.532416] Call Trace:
> [ 4356.532443]  [<c185c836>] ? printk+0x1d/0x1f
> [ 4356.532467]  [<c12cde1f>] warn_alloc_failed+0xbf/0xf0
> [ 4356.532491]  [<c12d0aba>] __alloc_pages_nodemask+0x4ba/0x6a0
> [ 4356.532521]  [<c12d0d1c>] __get_free_pages+0x1c/0x30
> [ 4356.532541]  [<c12f51e1>] kmalloc_order_trace+0x21/0xd0
> [ 4356.532561]  [<c131d0f7>] ? seq_read+0x137/0x390
> [ 4356.532579]  [<c12f549a>] __kmalloc+0x20a/0x230
> [ 4356.532596]  [<c131d0f7>] ? seq_read+0x137/0x390
> [ 4356.532616]  [<c12d343c>] ? put_page+0x2c/0x40
> [ 4356.532634]  [<c12f4a7d>] ? kfree+0xcd/0x160
> [ 4356.532655]  [<c18656cd>] ? mutex_unlock+0xd/0x10
> [ 4356.532675]  [<c131d109>] seq_read+0x149/0x390
> [ 4356.532697]  [<c130062c>] vfs_read+0x8c/0x160
> [ 4356.532716]  [<c131cfc0>] ? seq_lseek+0x180/0x180
> [ 4356.532735]  [<c130073d>] sys_read+0x3d/0x70
> [ 4356.532755]  [<c1866e91>] syscall_call+0x7/0xb
> [ 4356.532777]  [<c1860000>] ? log_dir_items+0x33d/0x40c
>
> the m->size is very huge
> <3>[ 1185.457656, 1] xiaobing >> seq_read: m->size 8192
> <3>[ 1185.463462, 1] xiaobing >> seq_read: m->size 16384
> <3>[ 1185.470472, 1] xiaobing >> seq_read: m->size 32768
> <3>[ 1185.481201, 0] xiaobing >> seq_read: m->size 8192
> <3>[ 1185.488071, 0] xiaobing >> seq_read: m->size 16384
> <3>[ 1185.495892, 0] xiaobing >> seq_read: m->size 32768
> <3>[ 1185.504841, 0] xiaobing >> seq_read: m->size 65536
> <3>[ 1185.517180, 0] xiaobing >> seq_read: m->size 131072
> <3>[ 1185.536286, 0] xiaobing >> seq_read: m->size 262144
>
> some times even more then 262144 byte
>
> Signed-off-by: xiaobing tu <xiaobing.tu@intel.com>
> Change-Id: I892c97d02cf25e59b23c9bc68dff754ea01c1d56
> ---
>  fs/seq_file.c |   22 +++++++++++++++++-----
>  1 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/fs/seq_file.c b/fs/seq_file.c
> index dba43c3..19df826 100644
> --- a/fs/seq_file.c
> +++ b/fs/seq_file.c
> @@ -12,7 +12,7 @@
>
>  #include <asm/uaccess.h>
>  #include <asm/page.h>
> -
> +#include <linux/mm.h>
>  /**
>   *    seq_open -    initialize sequential file
>   *    @file: file we initialize
> @@ -116,7 +116,13 @@ static int traverse(struct seq_file *m, loff_t 
> offset)
>  Eoverflow:
>      m->op->stop(m, p);
>      kfree(m->buf);
> -    m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
> +
> +    is_vmalloc_addr(m->buf) ? vfree(m->buf) : kfree(m->buf);
> +    m->size <<= 1;
> +    if (m->size <= (2 * PAGE_SIZE))
> +        m->buf = kmalloc(m->size, GFP_KERNEL);
> +    else
> +        m->buf = vmalloc(m->size);
>      return !m->buf ? -ENOMEM : -EAGAIN;
>  }
>
> @@ -209,8 +215,14 @@ ssize_t seq_read(struct file *file, char __user 
> *buf, size_t size, loff_t *ppos)
>          if (m->count < m->size)
>              goto Fill;
>          m->op->stop(m, p);
> -        kfree(m->buf);
> -        m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
> +        is_vmalloc_addr(m->buf) ? vfree(m->buf) : kfree(m->buf);
> +        m->size <<= 1;
> +        if (m->size > 2 * PAGE_SIZE)
> +            m->buf = vmalloc(m->size);
> +        else
> +            m->buf = kmalloc(m->size, GFP_KERNEL);
> +
> +
>          if (!m->buf)
>              goto Enomem;
>          m->count = 0;
> @@ -325,7 +337,7 @@ EXPORT_SYMBOL(seq_lseek);
>  int seq_release(struct inode *inode, struct file *file)
>  {
>      struct seq_file *m = file->private_data;
> -    kfree(m->buf);
> +    is_vmalloc_addr(m->buf) ? vfree(m->buf) : kfree(m->buf);
>      kfree(m);
>      return 0;
>  }


      parent reply	other threads:[~2013-02-01  3:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-29  6:14 Avoid high order memory allocating with kmalloc, when read large seq file xtu4
2013-01-29 21:49 ` David Rientjes
2013-01-31  6:19   ` Tu, Xiaobing
2013-01-30  0:24 ` Andrew Morton
2013-01-31  6:19   ` Tu, Xiaobing
2013-01-31  6:11 ` resend----[PATCH] " xtu4
2013-01-31 21:27   ` Andrew Morton
2013-02-01  3:30   ` xtu4
2013-02-01  3:31   ` xtu4 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=510B3700.5070602@intel.com \
    --to=xiaobing.tu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=guifang.tang@intel.com \
    --cc=linX.z.chen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yanmin.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.