All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Huang <wei@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Amit Shah <amit.shah@redhat.com>,
	Andrew Jones <drjones@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/1] virtio-mmio: return the max queue num of virtio-mmio with initial value
Date: Mon, 20 Jul 2015 10:38:58 -0500	[thread overview]
Message-ID: <55AD1612.9090603@redhat.com> (raw)
In-Reply-To: <CAFEAcA8ymYne301xk6pHbJDw09zK+b1irwyuPUXnU7MmaVQQ4w@mail.gmail.com>



On 07/20/2015 06:07 AM, Peter Maydell wrote:
> On 16 July 2015 at 19:38, Wei Huang <wei@redhat.com> wrote:
>> Recently we found that virtio-console devices consumes lots AArch64 guest
>> memory, roughly 1GB with 8 devices. After debugging, it turns out that lots
>> of factors contribute to this problem: i) guest PAGE_SIZE=64KB, ii)
>> virtio-mmio based devices, and iii) virtio-console device. Here is the
>> detailed analysis:
>>
>> 1. First, during initialization, virtio-mmio driver in guest pokes vq
>>    size by reading VIRTIO_MMIO_QUEUE_NUM_MAX (see virtio_mmio.c file).
>> 2. QEMU returns VIRTQUEUE_MAX_SIZE (1024) to guest VM; And virtio-mmio uses
>>    it as the default vq size.
>> 3. virtio-console driver allocates vring buffers based on this value (see
>>    add_inbuf() function of virtio_console.c file). Because PAGE_SIZE=64KB,
>>    ~64MB is allocated for each virtio-console vq.
>>
>> This patch addresses the problem by returning the iniatlized vring size
>> when VM queries QEMU about VIRTIO_MMIO_QUEUE_NUM_MAX. This is similar to
>> virtio-pci's approach. By doing this, the vq memory consumption is reduced
>> substantially.
> 
> I don't know if this patch is sensible to apply anyway, but from
> this description this really sounds like a guest kernel bug.
> QEMU tells the kernel the maximum queue size it can cope with,
> and if the guest kernel cares about not using insane amounts of
> RAM on queues then it should not blindly use the maximum size
> but restrict it itself...
Yes, this is another way of solving the problem. I think there are three
alternatives:

1. Fix the return value of MMIO_QUEUE_NUM_MAX in QEMU (my patch);
2. In guest VM, virtio-mmio shouldn't query MMIO_QUEUE_NUM_MAX. Instead,
it should behave similarly to virtio-pci driver which queries
VIRTIO_PCI_QUEUE_NUM instead. However this approach requires
modification of VIRTIO Specification as VIRTIO_PCI_QUEUE_NUM is
WRITE-ONLY in virtio-mmio.
3. Fix virtio_console driver in guest VM. This driver currently takes in
info->num and allocates memory based on its value. Apparently we can put
a upper-limit on it.

Your suggestion could fall in to (2) or (3). Any preference?

Thanks,
-Wei



> 
> thanks
> -- PMM
> 

  reply	other threads:[~2015-07-20 15:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-16 18:38 [Qemu-devel] [PATCH 1/1] virtio-mmio: return the max queue num of virtio-mmio with initial value Wei Huang
2015-07-20 11:07 ` Peter Maydell
2015-07-20 15:38   ` Wei Huang [this message]
2015-07-21 11:22     ` Andrew Jones

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=55AD1612.9090603@redhat.com \
    --to=wei@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=drjones@redhat.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.