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
next prev parent 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