From: yunhong jiang <yunhong.jiang@linux.intel.com>
To: Chris Metcalf <cmetcalf@mellanox.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Questions on the task isolation patches
Date: Thu, 1 Dec 2016 14:28:12 -0800 [thread overview]
Message-ID: <20161201142812.369f23f8@jnakajim-build> (raw)
Hi, Chris
I noticed your task isolation patch set at
https://lkml.org/lkml/2016/8/9/759 . Thanks a lot for the great effort.
I checked the patch and have some questions about how to use this
functionality on the NFV environment. In the NFV scenario, high speed network
code runs on a VM user space and the VM is hosted by KVM hypervisor. To achieve
the high speed network, not only the network code should be isolated, also the
vCPU thread.
I checked your patch to think how to isolate the vCPU thread, and I have
some questions and hope your hints:
a) If the task isolation need prctl to mark itself as isolated,
possibly the vCPU thread can't achieve it. First, the vCPU thread may
need system service during OS booting time, also it's the application,
instead of the vCPU thread to decide if the vCPU thread should be
isolated. So possibly we need a mechanism so that another process can
set the vCPU thread's task isolation?
b) I noticed that curently the task_isolation_prepare() is invoked on
exit_to_usermode_loop(), while we may need such job on VM Exit procedure, or
interrupt handling during VM exit handling.
Also, I'm also considering how to utilize this task_isolation for network
node which is not busy-loop, like the interrupt mode DPDK code. In the
interrupt mode DPDK code, the application may yield the CPU if there is no
network packet for a very long time and it will re-enter the busy loop mode
once new packet arrived. This interrupt mode will be helpful for both power
management and resource utilization. Per my understanding, the application
should turn off the task isolation before yield the CPU and the restart the
task isolation after the new packet, right?
Thanks
--jyh
next reply other threads:[~2016-12-01 22:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-01 22:28 yunhong jiang [this message]
2016-12-02 18:58 ` Chris Metcalf
2016-12-06 21:43 ` yunhong jiang
2016-12-16 21:00 ` Chris Metcalf
2016-12-17 1:00 ` yunhong jiang
2016-12-20 9:27 ` Paolo Bonzini
2016-12-22 20:56 ` Chris Metcalf
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=20161201142812.369f23f8@jnakajim-build \
--to=yunhong.jiang@linux.intel.com \
--cc=cmetcalf@mellanox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/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
all inboxes | Powered by JetHome®