From: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
To: kvm-ia64@vger.kernel.org
Subject: Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving
Date: Mon, 24 May 2010 07:05:29 +0000 [thread overview]
Message-ID: <4BFA2539.3030709@oss.ntt.co.jp> (raw)
(2010/05/17 18:06), Takuya Yoshikawa wrote:
>
>> User allocated bitmaps have the advantage of reducing pinned memory.
>> However we have plenty more pinned memory allocated in memory slots, so
>> by itself, user allocated bitmaps don't justify this change.
Sorry for pinging several times.
>
> In that sense, what do you think about the question I sent last week?
>
> == REPOST 1 => >>
> >> mark_page_dirty is called with the mmu_lock spinlock held in set_spte.
> >> Must find a way to move it outside of the spinlock section.
I am now trying to do something to solve this spinlock problem. But the
spinlock section looks too wide to solve with simple workaround.
> 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.
Thanks,
Takuya
>
> I know that the resource for vmalloc() is precious for x86 but even now,
> at the timing
> of get_dirty_log, we use the same amount of memory as double buffering.
> == 1 END =>
>
>>
>> Perhaps if we optimize memory slot write protection (I have some ideas
>> about this) we can make the performance improvement more pronounced.
>>
>
> It's really nice!
>
> Even now we can measure the performance improvement by introducing
> switch ioctl
> when guest is relatively idle, so the combination will be really effective!
>
> == REPOST 2 => >>
> >> Can you post such a test, for an idle large guest?
> >
> > OK, I'll do!
>
>
> Result of "low workload test" (running top during migration) first,
>
> 4GB guest
> picked up slots[1](len757047808) only
> *****************************************
> get.org get.opt switch.opt
>
> 1060875 310292 190335
> 1076754 301295 188600
> 655504 318284 196029
> 529769 301471 325
> 694796 70216 221172
> 651868 353073 196184
> 543339 312865 213236
> 1061938 72785 203090
> 689527 323901 249519
> 621364 323881 473
> 1063671 70703 192958
> 915903 336318 174008
> 1046462 332384 782
> 1037942 72783 190655
> 680122 318305 243544
> 688156 314935 193526
> 558658 265934 190550
> 652454 372135 196270
> 660140 68613 352
> 1101947 378642 186575
> ... ... ...
> *****************************************
>
> As expected we've got the difference more clearly.
>
> In this case, switch.opt reduced 1/3 (.1 msec) compared to get.opt
> for each iteration.
>
> And when the slot is cleaner, the ratio is bigger.
> == 2 END => --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next reply other threads:[~2010-05-24 7:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-24 7:05 Takuya Yoshikawa [this message]
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
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=4BFA2539.3030709@oss.ntt.co.jp \
--to=yoshikawa.takuya@oss.ntt.co.jp \
--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).