similar to: [PATCH] vhost: do not enable VHOST_MENU by default

Hi Jason, I love your patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on next-20200414] [cannot apply to powerpc/next s390/features v5.7-rc1] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please

We try to keep the defconfig untouched after decoupling CONFIG_VHOST out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by default. Then the defconfigs can keep enabling CONFIG_VHOST_NET without the caring of CONFIG_VHOST. But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even for the ones that

We try to keep the defconfig untouched after decoupling CONFIG_VHOST out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by default. Then the defconfigs can keep enabling CONFIG_VHOST_NET without the caring of CONFIG_VHOST. But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even for the ones that

On 14.04.20 04:44, Jason Wang wrote: > We try to keep the defconfig untouched after decoupling CONFIG_VHOST > out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a > ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by > default. Then the defconfigs can keep enabling CONFIG_VHOST_NET > without the caring of CONFIG_VHOST. > > But this will leave a

On Wed, Apr 15, 2020 at 10:43:56AM +0800, Jason Wang wrote: > We try to keep the defconfig untouched after decoupling CONFIG_VHOST > out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a > ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by > default. Then the defconfigs can keep enabling CONFIG_VHOST_NET > without the caring of CONFIG_VHOST. > > But

Hi everyone, I have a question about cgroup's policy concerning the treatment of threads. Please consider that we want to attach an application which has some threads already to a certain cgroup. If we echo the pid of this application to the "tasks" file connected to this cgroup the threads belonging to this application will NOT be moved to the new group. Is it right? If so, is

Hi everyone, I have a question about cgroup's policy concerning the treatment of threads. Please consider that we want to attach an application which has some threads already to a certain cgroup. If we echo the pid of this application to the "tasks" file connected to this cgroup the threads belonging to this application will NOT be moved to the new group. Is it right? If so, is

Hello, I have summarized the topics for the IO controller mini-summit and written the ideas seen in the mailing list. - The place where IO controller should be implemented - Block layer in conjunction with the IO scheduler - Common layer right above the IO scheduler - CFQ enhancement. - Both block and common layer, users can select whichever controller they want. - VFS layer -

Hello, I have summarized the topics for the IO controller mini-summit and written the ideas seen in the mailing list. - The place where IO controller should be implemented - Block layer in conjunction with the IO scheduler - Common layer right above the IO scheduler - CFQ enhancement. - Both block and common layer, users can select whichever controller they want. - VFS layer -

Hello, I have summarized the topics for the IO controller mini-summit and written the ideas seen in the mailing list. - The place where IO controller should be implemented - Block layer in conjunction with the IO scheduler - Common layer right above the IO scheduler - CFQ enhancement. - Both block and common layer, users can select whichever controller they want. - VFS layer -

Hi All, I have got excellent results of dm-ioband, that controls the disk I/O bandwidth even when it accepts delayed write requests. In this time, I ran some benchmarks with a high-end storage. The reason was to avoid a performance bottleneck due to mechanical factors such as seek time. You can see the details of the benchmarks at: http://people.valinux.co.jp/~ryov/dm-ioband/hps/ Thanks, Ryo

Hi All, I have got excellent results of dm-ioband, that controls the disk I/O bandwidth even when it accepts delayed write requests. In this time, I ran some benchmarks with a high-end storage. The reason was to avoid a performance bottleneck due to mechanical factors such as seek time. You can see the details of the benchmarks at: http://people.valinux.co.jp/~ryov/dm-ioband/hps/ Thanks, Ryo

Hi All, I have got excellent results of dm-ioband, that controls the disk I/O bandwidth even when it accepts delayed write requests. In this time, I ran some benchmarks with a high-end storage. The reason was to avoid a performance bottleneck due to mechanical factors such as seek time. You can see the details of the benchmarks at: http://people.valinux.co.jp/~ryov/dm-ioband/hps/ Thanks, Ryo

Dear ALL Our company make and sell some measurement system controlled by Server. There is no technical issue but we don't have enough information about license. We will do the following, 1) We make the DVD image which include CentOS and our application. 2) Sell DVD to our customer. 3) Customer installs this image (CentOS and our applications) on the Server. Question 1 Is there no problem

Hello https://www.centos.org/legal/trademarks/ According to above, I found following message. ---------------------- Notwithstanding anything to the contrary provided in these Guidelines, the following are examples of unacceptable uses: 1.Use of the CentOS Marks in connection with commercial redistribution of CentOS software ---------------------- I have a question. What means "Use of the

Hi, The following patch adds ioprio to blktrace. Explanation: As you know, I/O schedulers such as cfq use io_contexts of current tasks to schedule block I/O. But recently, some are suggesting to use more appropriate io_contexts obtained by, for example, doing io-tracking, making struct bio have io_context member, etc. I thought adding ioprio to blktrace output might be helpful. Implementation:

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: b072ae74df177c3ad7704c5fbe66e3f10aad9d4e commit: b072ae74df177c3ad7704c5fbe66e3f10aad9d4e [12/12] vhost: use vhost_desc instead of vhost_log config: s390-debug_defconfig (attached as .config) compiler: s390-linux-gcc (GCC) 7.5.0 reproduce: wget

Hi everyone, This series of patches of dm-ioband now includes "The bio tracking mechanism," which has been posted individually to this mailing list. This makes it easy for anybody to control the I/O bandwidth even when the I/O is one of delayed-write requests. Have fun! This series of patches consists of two parts: 1. dm-ioband Dm-ioband is an I/O bandwidth controller implemented

Hi everyone, This series of patches of dm-ioband now includes "The bio tracking mechanism," which has been posted individually to this mailing list. This makes it easy for anybody to control the I/O bandwidth even when the I/O is one of delayed-write requests. Have fun! This series of patches consists of two parts: 1. dm-ioband Dm-ioband is an I/O bandwidth controller implemented

Hi everyone, This series of patches of dm-ioband now includes "The bio tracking mechanism," which has been posted individually to this mailing list. This makes it easy for anybody to control the I/O bandwidth even when the I/O is one of delayed-write requests. Have fun! This series of patches consists of two parts: 1. dm-ioband Dm-ioband is an I/O bandwidth controller implemented