[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161201142812.369f23f8@jnakajim-build>
Date: Thu, 1 Dec 2016 14:28:12 -0800
From: yunhong jiang <yunhong.jiang@...ux.intel.com>
To: Chris Metcalf <cmetcalf@...lanox.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Paolo Bonzini <pbonzini@...hat.com>
Subject: Questions on the task isolation patches
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
Powered by blists - more mailing lists