From: Mike Waychison <mikew@google.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
"Michael S. Tsirkin" <mst@redhat.com>
Cc: netdev@vger.kernel.org, earhart@google.com,
digitaleric@google.com, linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: [PATCH v2 0/3] virtio_net: Better low memory handling.
Date: Tue, 10 Jan 2012 09:40:54 -0800 [thread overview]
Message-ID: <20120110174052.4505.66514.stgit@mike2.sea.corp.google.com> (raw)
The following series applies to net-next.
The following series changes the low memory paths in virtio_net to not
disable NAPI while waiting in the allocator in the slow path.
It attempts to rectify some performance problems we've seen where the
network performance drops significantly when memory is low. The working
theory is that the disabling of NAPI while allocations are occuring in
the slow refill_work() path can in turn cause significant delays in
processing of the receive queue.
The observed situation on an unmodified kernel is that a system with low
memory will in turn quickly stop being being able to refill the rx queue
with buffers, in turn causing packets to be dropped by the host OS (as
NAPI polling is disabled) while the driver wait for memory to be
reclaimed. The way the process-context refill loop works, the memory
subsystem is effectively polled every half second when things look
bleak, leading to significant packet loss and congestion window
collapse.
The first patch prepares for a batched refill path by splitting the
receive buffer allocation and enqueue bits into separate functions.
The second patch introduces the batched refill path itself. As
implemented, it still disables NAPI completely for the whole refill.
The third patch then pushed the disabling and enabling of NAPI down into
the refill loop so that it only covers the actual enqueueing of receive
buffers on the virtqueue.
This patchset seems to help the test setups that I'm playing with.
Example tests include using several bit-torrent clients within a VM and
watching the network throughputs on the host. Other similar workloads
(high network traffic, reasonably high disk IO causing memory pressure)
also appear to have throughput problems alleviated by these changes.
As a warning, I've only tested this using the "small buffers" and
"mergeable" buffers paths. I haven't figured out how to force qemu-kvm
to not support the feature bits that trigger 'mergable' receive buffers.
ChangeLog:
==========
v2:
- Rewritten to not introduce a spinlock to protect the virtqueue data.
---
Mike Waychison (3):
virtio_net: Split receive buffer alloc/add
virtio_net: Batch receive buffer filling
virtio_net: Don't disable NAPI while allocating
drivers/net/virtio_net.c | 325 ++++++++++++++++++++++++++++++++++++++++------
1 files changed, 285 insertions(+), 40 deletions(-)
next reply other threads:[~2012-01-10 17:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 17:40 Mike Waychison [this message]
2012-01-10 17:41 ` [PATCH v2 1/3] virtio_net: Split receive buffer alloc/add Mike Waychison
2012-01-11 1:30 ` Rusty Russell
2012-01-11 1:42 ` Mike Waychison
2012-01-10 17:41 ` [PATCH v2 2/3] virtio_net: Batch receive buffer filling Mike Waychison
2012-01-10 17:41 ` [PATCH v2 3/3] virtio_net: Don't disable NAPI while allocating Mike Waychison
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=20120110174052.4505.66514.stgit@mike2.sea.corp.google.com \
--to=mikew@google.com \
--cc=digitaleric@google.com \
--cc=earhart@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.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