From: Andrea Arcangeli <aarcange@redhat.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: linux-mm@kvack.org, Marcelo Tosatti <mtosatti@redhat.com>,
Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
Izik Eidus <ieidus@redhat.com>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Nick Piggin <npiggin@suse.de>, Rik van Riel <riel@redhat.com>,
Mel Gorman <mel@csn.ul.ie>, Dave Hansen <dave@linux.vnet.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Ingo Molnar <mingo@elte.hu>, Mike Travis <travis@sgi.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Chris Wright <chrisw@sous-sol.org>,
bpicco@redhat.com,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Arnd Bergmann <arnd@arndb.de>,
"Michael S. Tsirkin" <mst@redhat.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 00 of 34] Transparent Hugepage support #14
Date: Thu, 25 Mar 2010 23:41:19 +0100 [thread overview]
Message-ID: <20100325224119.GY10659@random.random> (raw)
In-Reply-To: <alpine.DEB.2.00.1003251708170.10999@router.home>
On Thu, Mar 25, 2010 at 05:17:23PM -0500, Christoph Lameter wrote:
> On Wed, 24 Mar 2010, Andrea Arcangeli wrote:
>
> > On Wed, Mar 24, 2010 at 04:03:03PM -0500, Christoph Lameter wrote:
> > > If a delay is "altered behavior" then we should no longer run reclaim
> > > because it "alters" the behavior of VM functions.
> >
> > You're comparing the speed of ram with speed of disk. If why it's not
> > acceptable to me isn't clear try booting with mem=100m and I'm sure
> > you'll get it.
>
> Are you talking about the wait for writeback to be complete? Dirty pages
> can be migrated. With some effort you could avoid the writeback complete
> wait since you are not actually moving the page.
It seems we're derailing, let's try to go back to the context. You
said we can avoid get_page/put_page changes if we do like
migration. Migration bails out if there's a gup reference on the
page. It's _gup_ not writeback we're talking about. gup is used for
I/O too like O_DIRECT (which is mandatory feature for virtual
machines, if not for databases). So the I/O I'm talking about is the
one that any driver or subsystem can do after calling gup. And it's
not a lock on the page or a writeback bitflag, but the gup reference
that we're waiting the I/O to complete, in order to be released. Not
to tell drivers like old KVM pre-mmu-notifier that may never release
the gup reference (these days any driver keeping gup references for
"indefinite" time has to use mmu notifier to play nicely with the VM
but there will always be temporary I/O at the speed-of-disk and
hanging mprotect and mremap on that isn't ok with me).
--
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:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2010-03-25 22:42 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-17 15:19 [PATCH 00 of 34] Transparent Hugepage support #14 Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 01 of 34] define MADV_HUGEPAGE Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 02 of 34] compound_lock Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 03 of 34] alter compound get_page/put_page Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 04 of 34] update futex compound knowledge Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 05 of 34] fix bad_page to show the real reason the page is bad Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 06 of 34] clear compound mapping Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 07 of 34] add native_set_pmd_at Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 08 of 34] add pmd paravirt ops Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 09 of 34] no paravirt version of pmd ops Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 10 of 34] export maybe_mkwrite Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 11 of 34] comment reminder in destroy_compound_page Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 12 of 34] config_transparent_hugepage Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 13 of 34] special pmd_trans_* functions Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 14 of 34] add pmd mangling generic functions Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 15 of 34] add pmd mangling functions to x86 Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 16 of 34] bail out gup_fast on splitting pmd Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 17 of 34] pte alloc trans splitting Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 18 of 34] add pmd mmu_notifier helpers Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 19 of 34] clear page compound Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 20 of 34] add pmd_huge_pte to mm_struct Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 21 of 34] split_huge_page_mm/vma Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 22 of 34] split_huge_page paging Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 23 of 34] clear_copy_huge_page Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 24 of 34] kvm mmu transparent hugepage support Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 25 of 34] _GFP_NO_KSWAPD Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 26 of 34] don't alloc harder for gfp nomemalloc even if nowait Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 27 of 34] transparent hugepage core Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 28 of 34] verify pmd_trans_huge isn't leaking Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 29 of 34] madvise(MADV_HUGEPAGE) Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 30 of 34] pmd_trans_huge migrate bugcheck Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 31 of 34] memcg compound Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 32 of 34] memcg huge memory Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 33 of 34] transparent hugepage vmstat Andrea Arcangeli
2010-03-17 15:19 ` [PATCH 34 of 34] khugepaged Andrea Arcangeli
2010-03-17 19:05 ` [PATCH 00 of 34] Transparent Hugepage support #14 Christoph Lameter
2010-03-18 23:49 ` Andrea Arcangeli
2010-03-19 13:29 ` Christoph Lameter
2010-03-19 14:41 ` Andrea Arcangeli
2010-03-22 15:38 ` Christoph Lameter
2010-03-22 16:35 ` Johannes Weiner
2010-03-22 16:46 ` Christoph Lameter
2010-03-22 17:15 ` Andrea Arcangeli
2010-03-23 17:08 ` Christoph Lameter
2010-03-22 18:20 ` Johannes Weiner
2010-03-23 17:11 ` Christoph Lameter
2010-03-23 19:06 ` Andrea Arcangeli
2010-03-22 17:08 ` Andrea Arcangeli
2010-03-22 17:06 ` Andrea Arcangeli
2010-03-23 17:06 ` Christoph Lameter
2010-03-23 19:08 ` Andrea Arcangeli
2010-03-24 21:03 ` Christoph Lameter
2010-03-24 21:22 ` Andrea Arcangeli
2010-03-25 22:17 ` Christoph Lameter
2010-03-25 22:41 ` Andrea Arcangeli [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=20100325224119.GY10659@random.random \
--to=aarcange@redhat.com \
--cc=agl@us.ibm.com \
--cc=arnd@arndb.de \
--cc=avi@redhat.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=bpicco@redhat.com \
--cc=chrisw@sous-sol.org \
--cc=cl@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=ieidus@redhat.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=npiggin@suse.de \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=travis@sgi.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;
as well as URLs for NNTP newsgroup(s).