From: Marcelo Tosatti <mtosatti@redhat.com>
To: kvm-ia64@vger.kernel.org
Subject: Re: Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic:
Date: Tue, 01 Jun 2010 12:54:27 +0000 [thread overview]
Message-ID: <20100601125427.GA5198@amt.cnet> (raw)
In-Reply-To: <4BFA2539.3030709@oss.ntt.co.jp>
On Tue, Jun 01, 2010 at 09:05:38PM +0900, Takuya Yoshikawa wrote:
> (2010/06/01 19:55), Marcelo Tosatti wrote:
>
> >>>Sorry but I have to say that mmu_lock spin_lock problem was completely
> >>>out of
> >>>my mind. Although I looked through the code, it seems not easy to move the
> >>>set_bit_user to outside of spinlock section without breaking the
> >>>semantics of
> >>>its protection.
> >>>
> >>>So this may take some time to solve.
> >>>
> >>>But personally, I want to do something for x86's "vmallc() every time"
> >>>problem
> >>>even though moving dirty bitmaps to user space cannot be achieved soon.
> >>>
> >>>In that sense, do you mind if we do double buffering without moving
> >>>dirty bitmaps to
> >>>user space?
> >>
> >>So I would be happy if you give me any comments about this kind of other
> >>options.
> >
> >What if you pin the bitmaps?
>
> Yes, pinning bitmaps works. The small problem is that we need to hold
> the dirty_bitmap_pages[] array for every slot, the size of this array
> depends on the slot length, and of course pinning itself.
>
> In the performance point of view, having double sized vmalloc'ed
> area may be better.
>
> >
> >The alternative to that is to move mark_page_dirty(gfn) before acquision
> >of mmu_lock, in the page fault paths. The downside of that is a
> >potentially (large?) number of false positives in the dirty bitmap.
> >
>
> Interesting, but probably dangerous.
>
>
> From my experience, though this includes my personal view, removing vmalloc
> currently used by x86 is the most simple and effective change.
>
> So if you don't mind, I want to double the size of vmalloc'ed area for x86
> without changing other parts.
>
> => if this one more bitmap is problematic, dirty logging itself would be
> in danger of failure: we need to have the same size in the timing of
> switch.
>
> Make sense?
That seems the most sensible approach.
>
> We can consider moving dirty bitmaps to user space later.
prev parent reply other threads:[~2010-06-01 12:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-24 7:05 Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving Takuya Yoshikawa
2010-06-01 10:55 ` Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: Marcelo Tosatti
2010-06-01 12:05 ` Takuya Yoshikawa
2010-06-01 12:54 ` Marcelo Tosatti [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=20100601125427.GA5198@amt.cnet \
--to=mtosatti@redhat.com \
--cc=kvm-ia64@vger.kernel.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).