From: Dave Hansen <haveblue@us.ibm.com>
To: Ashwin Rao <ashwin_s_rao@yahoo.com>
Cc: Valdis.Kletnieks@vt.edu,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: Atomic operation for physically moving a page (for memory defragmentation)
Date: Fri, 18 Jun 2004 21:25:38 -0700 [thread overview]
Message-ID: <1087619137.4921.93.camel@nighthawk> (raw)
In-Reply-To: <20040619031536.61508.qmail@web10902.mail.yahoo.com>
On Fri, 2004-06-18 at 20:15, Ashwin Rao wrote:
> The problem is the memory fragmentation. The code i am
> writing is for the memory defragmentation as proposed
> by Daniel Phillips, my project partner Alok mooley has
> given mailed a simple prototype in the mid of feb.
Ahhh.... *That* code :) Do you have an updated version you'd like to
share? I'm curious how you integrated the suggestions from February.
> > (*) Yes, I know the BKL isn't something you want to
> > grab if you can help it.
>
> Isnt it a bad idea to take the BKL, the performance of
> SMP systems will drastically be hampered.
Only during a defragment operation. Are you planning to run the system
under constant defragmentation?
> > However, if we're on an unlikely error path or
> > similar and other options aren't suitable...
>
> Maintaining atomicity in uniprocessor systems is easy
> by preempt_enable and preempt_disable during the
> operation. This implementation cannot be used for SMP
> systems.
> Now during the time a page is copied/updatede if a
> page is accessed the copied contents become invalid,
> as updation is not done. Also during updation a
> similar situation might arise.
> The problem we are facing is to maintain the atomicity
> of this operation on SMP boxes.
I think what you really want to do is keep anybody else from making a
new pte to the page, once you've invalidated all of the existing ones,
right?
Holding a lock_page() should do the trick. Anybody that goes any pulls
the page out of the page cache has to do a lock_page() and check
page->mapping before they can establish a pte to it, so you can stop
that. Since you're invalidating page->mapping before you move the page
(you *are* doing this, right?), it will end up working itself out.
-- Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <haveblue@us.ibm.com>
To: Ashwin Rao <ashwin_s_rao@yahoo.com>
Cc: Valdis.Kletnieks@vt.edu,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: Atomic operation for physically moving a page (for memory defragmentation)
Date: Fri, 18 Jun 2004 21:25:38 -0700 [thread overview]
Message-ID: <1087619137.4921.93.camel@nighthawk> (raw)
In-Reply-To: <20040619031536.61508.qmail@web10902.mail.yahoo.com>
On Fri, 2004-06-18 at 20:15, Ashwin Rao wrote:
> The problem is the memory fragmentation. The code i am
> writing is for the memory defragmentation as proposed
> by Daniel Phillips, my project partner Alok mooley has
> given mailed a simple prototype in the mid of feb.
Ahhh.... *That* code :) Do you have an updated version you'd like to
share? I'm curious how you integrated the suggestions from February.
> > (*) Yes, I know the BKL isn't something you want to
> > grab if you can help it.
>
> Isnt it a bad idea to take the BKL, the performance of
> SMP systems will drastically be hampered.
Only during a defragment operation. Are you planning to run the system
under constant defragmentation?
> > However, if we're on an unlikely error path or
> > similar and other options aren't suitable...
>
> Maintaining atomicity in uniprocessor systems is easy
> by preempt_enable and preempt_disable during the
> operation. This implementation cannot be used for SMP
> systems.
> Now during the time a page is copied/updatede if a
> page is accessed the copied contents become invalid,
> as updation is not done. Also during updation a
> similar situation might arise.
> The problem we are facing is to maintain the atomicity
> of this operation on SMP boxes.
I think what you really want to do is keep anybody else from making a
new pte to the page, once you've invalidated all of the existing ones,
right?
Holding a lock_page() should do the trick. Anybody that goes any pulls
the page out of the page cache has to do a lock_page() and check
page->mapping before they can establish a pte to it, so you can stop
that. Since you're invalidating page->mapping before you move the page
(you *are* doing this, right?), it will end up working itself out.
-- Dave
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-06-19 4:25 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-19 0:37 Atomic operation for physically moving a page Ashwin Rao
2004-06-19 0:37 ` Ashwin Rao
2004-06-19 1:03 ` Valdis.Kletnieks
2004-06-19 2:53 ` Dave Hansen
2004-06-19 2:53 ` Dave Hansen
2004-06-19 3:15 ` Atomic operation for physically moving a page (for memory defragmentation) Ashwin Rao
2004-06-19 3:15 ` Ashwin Rao
2004-06-19 3:34 ` Valdis.Kletnieks
2004-06-19 4:25 ` Dave Hansen [this message]
2004-06-19 4:25 ` Dave Hansen
2004-06-23 9:04 ` IWAMOTO Toshihiro
2004-06-23 9:04 ` IWAMOTO Toshihiro
2004-06-23 11:59 ` Hirokazu Takahashi
2004-06-23 11:59 ` Hirokazu Takahashi
2004-06-23 20:56 ` Dave Hansen
2004-06-23 20:56 ` Dave Hansen
2004-06-24 7:19 ` IWAMOTO Toshihiro
2004-06-24 7:19 ` IWAMOTO Toshihiro
2004-06-24 11:31 ` Dave Hansen
2004-06-24 11:31 ` Dave Hansen
2004-06-23 10:32 ` Hirokazu Takahashi
2004-06-23 10:32 ` Hirokazu Takahashi
2004-06-19 2:43 ` Atomic operation for physically moving a page Dave Hansen
2004-06-19 2:43 ` Dave Hansen
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=1087619137.4921.93.camel@nighthawk \
--to=haveblue@us.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=ashwin_s_rao@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/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.