public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: kosaki.motohiro@jp.fujitsu.com, Nick Piggin <npiggin@suse.de>,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
	lsf10-pc@lists.linuxfoundation.org, linux-scsi@vger.kernel.org
Subject: Re: [Lsf10-pc] Current MM topics for LSF10/MM Summit 8-9 August in Boston
Date: Tue, 22 Jun 2010 12:30:27 +0900 (JST)	[thread overview]
Message-ID: <20100622122813.B566.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <20100621131608.GW5787@random.random>

> On Mon, Jun 21, 2010 at 10:05:26PM +1000, Nick Piggin wrote:
> > Andrea Arcangeli	Transparent hugepages
> 
> Sure fine on my side. I got a proposal accepted for presentation at
> KVM Forum 2010 about it too the days after the VM summit too.
> 
> > KOSAKI Motohiro		get_user_pages vs COW problem
> 
> Just a side note, not sure exactly what is meant to be discussed about
> this bug, considering the fact this is still unsolved isn't technical
> problem as there were plenty of fixes available, and the one that seem
> to had better chance to get included was the worst one in my view, as
> it tried to fix it in a couple of gup caller (but failed, also because
> finding all put_page pin release is kind of a pain as they're spread
> all over the place and not identified as gup_put_page, and in addition
> to the instability and lack of completeness of the fix, it was also
> the most inefficient as it added unnecessary and coarse locking) plus
> all gup callers are affected, not just a few. I normally call it gup
> vs fork race. Luckily not all threaded apps uses O_DIRECT and fork and
> pretend to do the direct-io in different sub-page chunks of the same
> page from different threads (KVM would probably be affected if it
> didn't use MADV_DONTFORK on the O_DIRECT memory, as it might run fork
> to execute some network script when adding an hotplug pci net device
> for example). But surely we can discuss the fix we prefer for this
> bug, or at least we can agree it needs fixing.

If people don't want this. I'm ok to drop this. In my personal concern
most important topics are following four topics. (again it's only _my_
concern)


Rik van Riel		Memory management under virtualization (with KVM)
Andrea Arcangeli	Transparent hugepages
- mmap_sem scalability, again
- Direct reclaim, direct writeback problems




  parent reply	other threads:[~2010-06-22  3:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-16 20:50 Current topics for LSF10/MM Summit 8-9 August in Boston James Bottomley
2010-06-17  6:35 ` Nicholas A. Bellinger
2010-06-17 13:27   ` [Lsf10-pc] " James Bottomley
2010-06-17 16:00 ` Christof Schmitt
2010-06-17 16:07   ` James Bottomley
2010-06-17 16:13     ` Boaz Harrosh
2010-06-17 16:34     ` Vladislav Bolkhovitin
2010-06-17 16:42       ` James Bottomley
2010-06-17 17:11         ` Vladislav Bolkhovitin
2010-06-17 17:37           ` James Bottomley
2010-06-17 17:55             ` Vladislav Bolkhovitin
2010-06-18 11:41     ` Christof Schmitt
2010-06-18 12:18     ` [Lsf10-pc] " J. Bruce Fields
2010-06-21 12:05 ` Current MM " Nick Piggin
2010-06-21 13:16   ` [Lsf10-pc] " Andrea Arcangeli
2010-06-21 13:22     ` Gleb Natapov
2010-06-21 14:09       ` Andrea Arcangeli
2010-06-21 14:18         ` Gleb Natapov
2010-06-21 14:29           ` Andrea Arcangeli
2010-06-21 14:31             ` Avi Kivity
2010-06-21 14:45               ` Andrea Arcangeli
2010-06-22  3:30     ` KOSAKI Motohiro [this message]
2010-06-21 20:00   ` David Rientjes
2010-06-21 20:13     ` James Bottomley

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=20100622122813.B566.A69D9226@jp.fujitsu.com \
    --to=kosaki.motohiro@jp.fujitsu.com \
    --cc=aarcange@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lsf10-pc@lists.linuxfoundation.org \
    --cc=npiggin@suse.de \
    /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