All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH] Use direct memory allocation instead of memory pool during PV analysis (pvck)
Date: Mon, 29 Aug 2011 15:18:12 +0200	[thread overview]
Message-ID: <4E5B9194.70609@redhat.com> (raw)
In-Reply-To: <4E5B8CC5.3050001@redhat.com>

Dne 29.8.2011 14:57, Peter Rajnoha napsal(a):
> There's a very high memory usage when calling _pv_analyse_mda_raw (e.g. while
> executing pvck) that can end up with "out of memory".
> 
> _pv_analyse_mda_raw scans for metadata in the MDA, iteratively increasing the
> size to scan with SECTOR_SIZE until we find a probable config section or we're
> at the edge of the metadata area. However, when using a memory pool, we're also
> iteratively chasing for bigger and bigger mempool chunk which can't be found
> and so we're always allocating a new one, consuming more a more memory...
> (Even a 2MB metadata area can bring pvck down on my test machine!)
> 
> This patch just changes the mempool to direct memory allocation in this
> problematic part of the code.
> 

ACK

Using mempools for temporal buffers within non-critical section is not a good
idea.

Though it seems like mempools might get some 'enhancement' as well - as we
might trim/free the reserved preallocated chunk if it's not big enough for new
allocation. The usage of this 'optimalisation' is rather questionable - but it
would solve the problem visible here.


Zdenek



> Peter
> ---
>  lib/format_text/format-text.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/format_text/format-text.c b/lib/format_text/format-text.c
> index 4a025b2..513ac96 100644
> --- a/lib/format_text/format-text.c
> +++ b/lib/format_text/format-text.c
> @@ -226,7 +226,7 @@ static int _pv_analyze_mda_raw (const struct format_type * fmt,
>  		 * "maybe_config_section" returning true when there's no valid
>  		 * metadata in a sector (sectors with all nulls).
>  		 */
> -		if (!(buf = dm_pool_alloc(fmt->cmd->mem, size + size2)))
> +		if (!(buf = dm_malloc(size + size2)))
>  			goto_out;
>  
>  		if (!dev_read_circular(area->dev, offset, size,
> @@ -261,14 +261,14 @@ static int _pv_analyze_mda_raw (const struct format_type * fmt,
>  				size += SECTOR_SIZE;
>  			}
>  		}
> -		dm_pool_free(fmt->cmd->mem, buf);
> +		dm_free(buf);
>  		buf = NULL;
>  	}
>  
>  	r = 1;
>   out:
>  	if (buf)
> -		dm_pool_free(fmt->cmd->mem, buf);
> +		dm_free(buf);
>  	if (!dev_close(area->dev))
>  		stack;
>  	return r;
> 
> --
> lvm-devel mailing list
> lvm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/lvm-devel



      reply	other threads:[~2011-08-29 13:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-29 12:57 [PATCH] Use direct memory allocation instead of memory pool during PV analysis (pvck) Peter Rajnoha
2011-08-29 13:18 ` Zdenek Kabelac [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=4E5B9194.70609@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=lvm-devel@redhat.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.