From: Avi Kivity <avi@redhat.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>,
Marcelo Tosatti <mtosatti@redhat.com>,
Jan Kiszka <jan.kiszka@web.de>,
qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH] kvm: align ram_size to page boundary
Date: Sun, 17 Jun 2012 15:54:53 +0300 [thread overview]
Message-ID: <4FDDD39D.9090800@redhat.com> (raw)
In-Reply-To: <CAAu8pHtgapr1NwX7YZvZpKDUQ0C6xBHYJjGMwW3rK8LcpXDEpg@mail.gmail.com>
On 06/17/2012 03:43 PM, Blue Swirl wrote:
> On Sun, Jun 17, 2012 at 11:51 AM, Avi Kivity <avi@redhat.com> wrote:
>> On 06/17/2012 02:47 PM, Jan Kiszka wrote:
>>>>>
>>>>> I think this should rather go into generic code.
>>>>
>>>> To be honest, I put this in kvm-specific code because vl.c doesn't have
>>>> TARGET_PAGE_ALIGN. Maybe we should have machine->page_size or
>>>> machine->ram_alignment.
>>>>
>>>>> What sense does it make
>>>>> to have partial pages with TCG?
>>>>
>>>> Why impose an artificial restriction?
>>>
>>> Beca...
>>>
>>>>
>>>> (answer: to reduce differences among various accelerators)
>>>>
>>>
>>> Oh, you found the answer. :)
>>
>> Reducing round-trips across the Internet.
>>
>>>
>>> At least, it should be enforce for the x86 target, independent of the
>>> accelerator.
>>
>> Yeah. So there's machine->page_size or machine->ram_alignment. Not
>> sure which is best.
>
> The boards should make sure that the amount of RAM is feasible with
> the board memory slots. It's not possible to put 256kb SIMMs to a slot
> that expects 1GB DIMMs. We can allow some flexibility there though,
> I'm not sure if the current chipsets would support very much memory if
> we followed the docs to the letter.
Right. And generally memory modules are sized a power of two, creating
the silly "mega == 1048576" movement.
>
> Maybe strtosz() should just enforce 1MB granularity.
strtosz() is much too general. We could do it in vl.c without trouble.
However, it takes away our ability to emulate a "640k should be enough
for everyone" machine.
>
> What about ballooning (memory hotplug?), can that reduce the memory by
> smaller amount than page size?
Ballooning removes individual pages, that has no effect on the slot size.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-06-17 12:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-17 8:47 [Qemu-devel] [PATCH] kvm: align ram_size to page boundary Avi Kivity
2012-06-17 11:03 ` Jan Kiszka
2012-06-17 11:30 ` Avi Kivity
2012-06-17 11:47 ` Jan Kiszka
2012-06-17 11:51 ` Avi Kivity
2012-06-17 12:43 ` Blue Swirl
2012-06-17 12:48 ` Peter Maydell
2012-06-17 12:54 ` Avi Kivity [this message]
2012-06-17 13:06 ` Blue Swirl
2012-06-17 13:14 ` Avi Kivity
2012-07-06 18:50 ` Michael Tokarev
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=4FDDD39D.9090800@redhat.com \
--to=avi@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=mjt@tls.msk.ru \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.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 NNTP newsgroup(s).