From: mathieu.desnoyers@efficios.com (Mathieu Desnoyers)
Subject: [lttng-dev] [PATCH lttng-modules] Fix: Building the event list fails on fragmented memory
Date: Wed, 10 Jun 2015 07:14:54 +0000 (UTC) [thread overview]
Message-ID: <1905517223.241.1433920494952.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <55755E0D.7010902@leisener.de>
Hi Martin,
Can you reformat your patch with diff -urN so I can apply it with patch ?
Thanks!
Mathieu
----- On Jun 8, 2015, at 11:19 AM, Martin Leisener martin at leisener.de wrote:
> Hi Mathieu,
>
> thanks for merging my arm patch! I found one more issue during my lttng-modules
> usages,
> which can happen in low/fragmented memory situations. Please have a look, if you
> find this
> patch useful/mergable. Again it is tested on x86 Ubuntu 12.04 LTS as well as my
> imx6 arm board.
>
> Regards Martin
>
>
> On a small arm imx6 solo with 256MB RAM it often happens that memory becomes
> fragmented rather
> quickly, so that kmalloc will not be able to get enough consecutive pages
> (enocuntered for
> example if you enable all kernel events: lttng enable-event -k syscall --all).
>
> This patch switches the allocation to vmalloc. Tested for x86 on Ubuntu 12.04
> Lts
> and on imx6 solo 256MB RAM
>
> If this patch is not applied, you can identify low and/or fragmented memory
> failures by
> looking at the kernel ring buffer (please ignore DMA, it is due to some memory
> setup
> misconfiguration, should read Normal):
>
> ...
> [ 321.993820] lttng-sessiond: page allocation failure: order:4, mode:0x1040d0
> ...
> [ 321.994711] lowmem_reserve[]: 0 0 0
> [ 321.994727] DMA: 801*4kB (UEMC) 424*8kB (EMC) 355*16kB (UEMC) 344*32kB (MC)
> 340*64kB (C) 8*128kB (C) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB
> 0*16384kB 0*32768kB = 46068kB
>
> Signed-off-by: Martin Leisener <martin at leisener.de>
> ---
> lttng-events.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/lttng-events.c b/lttng-events.c
> index 7eec04c..c861f71 100644
> --- a/lttng-events.c
> +++ b/lttng-events.c
> @@ -39,6 +39,7 @@
> #include "wrapper/file.h"
> #include <linux/jhash.h>
> #include <linux/uaccess.h>
> +#include <linux/vmalloc.h>
> #include "wrapper/uuid.h"
> #include "wrapper/vmalloc.h" /* for wrapper_vmalloc_sync_all() */
> @@ -132,10 +133,10 @@ struct lttng_session *lttng_session_create(void)
> GFP_KERNEL);
> if (!metadata_cache)
> goto err_free_session;
> - metadata_cache->data = kzalloc(METADATA_CACHE_DEFAULT_SIZE,
> - GFP_KERNEL);
> + metadata_cache->data = vmalloc(METADATA_CACHE_DEFAULT_SIZE);
> if (!metadata_cache->data)
> goto err_free_cache;
> + memset(metadata_cache->data, 0, METADATA_CACHE_DEFAULT_SIZE);
> metadata_cache->cache_alloc = METADATA_CACHE_DEFAULT_SIZE;
> kref_init(&metadata_cache->refcount);
> session->metadata_cache = metadata_cache;
> @@ -162,7 +163,7 @@ void metadata_cache_destroy(struct kref *kref)
> {
> struct lttng_metadata_cache *cache =
> container_of(kref, struct lttng_metadata_cache, refcount);
> - kfree(cache->data);
> + vfree(cache->data);
> kfree(cache);
> }
> @@ -1523,10 +1524,15 @@ int lttng_metadata_printf(struct lttng_session *session,
> tmp_cache_alloc_size = max_t(unsigned int,
> session->metadata_cache->cache_alloc + len,
> session->metadata_cache->cache_alloc << 1);
> - tmp_cache_realloc = krealloc(session->metadata_cache->data,
> - tmp_cache_alloc_size, GFP_KERNEL);
> + tmp_cache_realloc = vmalloc(tmp_cache_alloc_size);
> if (!tmp_cache_realloc)
> goto err;
> + else if (session->metadata_cache->data) {
> + memset(tmp_cache_realloc, 0, tmp_cache_alloc_size);
> + memcpy(tmp_cache_realloc, session->metadata_cache->data,
> session->metadata_cache->cache_alloc);
> + vfree(session->metadata_cache->data);
> + }
> +
> session->metadata_cache->cache_alloc = tmp_cache_alloc_size;
> session->metadata_cache->data = tmp_cache_realloc;
> }
> --
> 1.7.9.5
>
>
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2015-06-10 7:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 9:19 Martin Leisener
2015-06-10 7:14 ` Mathieu Desnoyers [this message]
2015-06-10 13:17 ` Martin Leisener
2015-06-13 19:32 ` Mathieu Desnoyers
2015-06-15 18:27 ` Martin Leisener
2015-06-15 19:30 ` Mathieu Desnoyers
2015-06-23 13:46 ` Jan Glauber
2015-06-23 19:46 ` Mathieu Desnoyers
2015-06-23 20:21 ` Mathieu Desnoyers
2015-06-23 21:04 ` Mathieu Desnoyers
2015-06-25 8:08 ` Jan Glauber
2015-06-25 13:00 ` Mathieu Desnoyers
2015-06-25 13:37 ` Mathieu Desnoyers
2015-06-25 13:50 ` Jan Glauber
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=1905517223.241.1433920494952.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox