mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kevin Corry <kevcorry@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: evms-devel@lists.sourceforge.net,
	rajesh_ghanekar@persistent.co.in, dm-devel@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Evms-devel] dm snapshot problem
Date: Thu, 13 Jan 2005 21:42:26 -0600	[thread overview]
Message-ID: <200501132142.26663.kevcorry@us.ibm.com> (raw)
In-Reply-To: <20050113143443.56bd4977.akpm@osdl.org>

On Thursday 13 January 2005 16:34, Andrew Morton wrote:
> Kevin Corry <kevcorry@us.ibm.com> wrote:
> > > It would be better if dm could use highmem pages for this operation.
> >
> > What's the appropriate mechanism for telling the kernel to use highmem
> > for these structures? Each of these slabs (dm_io and dm_tio) are created
> > with kmem_cache_create(), and I don't see any corresponding flags in
> > slab.h that mention anything about highmem. Items are allocated from this
> > slab through mempool_alloc() with GFP_NOIO, since we're in the middle of
> > processing I/O requests and don't want to start new I/O in order to get
> > memory. Would it be proper to call mempool_alloc(pool,
> > GFP_NOIO|__GFP_HIGHMEM)?
>
> Oh.  slab structures can only be in lowmem.  I thought that you were saying
> that the actual I/O data was being copied, and only into lowmem pages.

Now that you mention it, the memory pages to hold the copied data is allocated 
at the time the snapshot device is activated, and uses 
alloc_page(GFP_KERNEL). Should we switch this to alloc_page(GFP_HIGHUSER)? I 
don't see many other places in the kernel tree that use this flag.

Of course, the number of these pages is currently a fixed limit per snapshot 
device (as I mentioned in an earlier reply), so it's kind of unlikely that 
these pages are a significant source of the memory usage that we're seeing in 
this test.

I'll see if I can start working on some improved congestion handling in DM. 
Hopefully that will make a noticeable difference.

Thanks for the help!
-- 
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net


  reply	other threads:[~2005-01-14  3:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <41E35950.9040201@persistent.co.in>
     [not found] ` <200501110834.42839.kevcorry@us.ibm.com>
     [not found]   ` <41E5116E.7000709@persistent.co.in>
2005-01-12 16:36     ` Kevin Corry
2005-01-13  6:51       ` Andrew Morton
2005-01-13 21:26         ` Kevin Corry
2005-01-13 22:34           ` Andrew Morton
2005-01-14  3:42             ` Kevin Corry [this message]
2005-01-14  3:44               ` Andrew Morton
     [not found]     ` <20050112183549.GA14782@osdl.org>
2005-01-13 21:58       ` Kevin Corry

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=200501132142.26663.kevcorry@us.ibm.com \
    --to=kevcorry@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=dm-devel@redhat.com \
    --cc=evms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rajesh_ghanekar@persistent.co.in \
    /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

Powered by JetHome