* [PATCH v2 0/6] [media] pci: use generic power management
From: Vaibhav Gupta @ 2020-07-17 3:56 UTC (permalink / raw)
To: Bjorn Helgaas, Bjorn Helgaas, Bjorn Helgaas, Vaibhav Gupta,
Mauro Carvalho Chehab
Cc: Vaibhav Gupta, linux-kernel, linux-media, linux-kernel-mentees,
Shuah Khan
Linux Kernel Mentee: Remove Legacy Power Management.
The purpose of this patch series is to upgrade power management in media
drivers. This has been done by upgrading .suspend() and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not change the
order of operations executed in a driver. Thus, does not change its behavior.
In general, drivers with legacy PM, .suspend() and .resume() make use of PCI
helper functions like pci_enable/disable_device_mem(), pci_set_power_state(),
pci_save/restore_state(), pci_enable/disable_device(), etc. to complete
their job.
The conversion requires the removal of those function calls, change the
callbacks' definition accordingly and make use of dev_pm_ops structure.
v2: v1 possibly broke cx23885 and cx25821.
All patches are compile-tested only.
Test tools:
- Compiler: gcc (GCC) 10.1.0
- allmodconfig build: make -j$(nproc) W=1 all
Vaibhav Gupta (6):
sta2x11: use generic power management
cx23885: use generic power management
cx25821: use generic power management
cx88: use generic power management
meye: use generic power management
tw68: use generic power management
drivers/media/pci/cx23885/cx23885-core.c | 3 --
drivers/media/pci/cx25821/cx25821-core.c | 3 --
drivers/media/pci/cx88/cx88-video.c | 52 +++++--------------
drivers/media/pci/meye/meye.c | 15 ++----
drivers/media/pci/sta2x11/sta2x11_vip.c | 63 ++++++------------------
drivers/media/pci/tw68/tw68-core.c | 30 +++++------
6 files changed, 44 insertions(+), 122 deletions(-)
--
2.27.0
^ permalink raw reply
* [Linux-kernel-mentees] [PATCH v2 0/6] [media] pci: use generic power management
From: Vaibhav Gupta @ 2020-07-17 3:56 UTC (permalink / raw)
To: Bjorn Helgaas, Bjorn Helgaas, Bjorn Helgaas, Vaibhav Gupta,
Mauro Carvalho Chehab
Cc: linux-media, linux-kernel-mentees, linux-kernel, Vaibhav Gupta
Linux Kernel Mentee: Remove Legacy Power Management.
The purpose of this patch series is to upgrade power management in media
drivers. This has been done by upgrading .suspend() and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not change the
order of operations executed in a driver. Thus, does not change its behavior.
In general, drivers with legacy PM, .suspend() and .resume() make use of PCI
helper functions like pci_enable/disable_device_mem(), pci_set_power_state(),
pci_save/restore_state(), pci_enable/disable_device(), etc. to complete
their job.
The conversion requires the removal of those function calls, change the
callbacks' definition accordingly and make use of dev_pm_ops structure.
v2: v1 possibly broke cx23885 and cx25821.
All patches are compile-tested only.
Test tools:
- Compiler: gcc (GCC) 10.1.0
- allmodconfig build: make -j$(nproc) W=1 all
Vaibhav Gupta (6):
sta2x11: use generic power management
cx23885: use generic power management
cx25821: use generic power management
cx88: use generic power management
meye: use generic power management
tw68: use generic power management
drivers/media/pci/cx23885/cx23885-core.c | 3 --
drivers/media/pci/cx25821/cx25821-core.c | 3 --
drivers/media/pci/cx88/cx88-video.c | 52 +++++--------------
drivers/media/pci/meye/meye.c | 15 ++----
drivers/media/pci/sta2x11/sta2x11_vip.c | 63 ++++++------------------
drivers/media/pci/tw68/tw68-core.c | 30 +++++------
6 files changed, 44 insertions(+), 122 deletions(-)
--
2.27.0
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply
* Re: [PATCH V2 2/2] arm64: imx: Select TPM driver by default
From: Daniel Lezcano @ 2020-07-17 3:57 UTC (permalink / raw)
To: Anson Huang, catalin.marinas, will, tglx, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1594178168-13007-2-git-send-email-Anson.Huang@nxp.com>
On 08/07/2020 05:16, Anson Huang wrote:
> Select CLKSRC_IMX_TPM for ARCH_MXC by default.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> No change.
> ---
> arch/arm64/Kconfig.platforms | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 8dd05b2..c52b7a0 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -169,6 +169,7 @@ config ARCH_MXC
> bool "ARMv8 based NXP i.MX SoC family"
> select ARM64_ERRATUM_843419
> select ARM64_ERRATUM_845719 if COMPAT
> + select CLKSRC_IMX_TPM
> select IMX_GPCV2
> select IMX_GPCV2_PM_DOMAINS
> select PM
Shall I take this patch also or just 1/2 ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v2 16/20] coresight: allow cti to be built as a module
From: tingwei @ 2020-07-17 3:55 UTC (permalink / raw)
To: Mike Leach
Cc: tsoni, Sai Prakash Ranjan, Kim Phillips, Mathieu Poirier,
Suzuki K Poulose, Alexander Shishkin, Greg Kroah-Hartman,
Coresight ML, Mao Jinlong, Mian Yousaf Kaukab, Russell King,
Randy Dunlap, Leo Yan, linux-arm-kernel, linux-arm-kernel
In-Reply-To: <CAJ9a7Vj8O-WfD4aXcV+Tiw+k9j45bLKbRmZL8F8xnpOrU1LGCA@mail.gmail.com>
On 2020-07-16 21:30, Mike Leach wrote:
> Hi,
>
> On Tue, 14 Jul 2020 at 06:54, Tingwei Zhang <tingwei@codeaurora.org>
> wrote:
>>
>> Allow to build coresight-cti as a module, for ease of development.
>>
>> - Kconfig becomes a tristate, to allow =m
>> - append -core to source file name to allow module to
>> be called coresight-cti by the Makefile
>> - add an cti_remove function, for module unload
>> - add a MODULE_DEVICE_TABLE for autoloading on boot
>>
>> Signed-off-by: Tingwei Zhang <tingwei@codeaurora.org>
>> ---
>> drivers/hwtracing/coresight/Kconfig | 5 ++++-
>> drivers/hwtracing/coresight/Makefile | 4 ++--
>> .../{coresight-cti.c => coresight-cti-core.c} | 14
>> ++++++++++++++
>> drivers/hwtracing/coresight/coresight-platform.c | 1 +
>> drivers/hwtracing/coresight/coresight.c | 1 +
>> 5 files changed, 22 insertions(+), 3 deletions(-)
>> rename drivers/hwtracing/coresight/{coresight-cti.c =>
> coresight-cti-core.c} (98%)
>>
>> diff --git a/drivers/hwtracing/coresight/Kconfig
> b/drivers/hwtracing/coresight/Kconfig
>> index f31778dd0b5d..b04aae2ceecc 100644
>> --- a/drivers/hwtracing/coresight/Kconfig
>> +++ b/drivers/hwtracing/coresight/Kconfig
>> @@ -136,7 +136,7 @@ config CORESIGHT_CPU_DEBUG
>> module will be called coresight-cpu-debug.
>>
>> config CORESIGHT_CTI
>> - bool "CoreSight Cross Trigger Interface (CTI) driver"
>> + tristate "CoreSight Cross Trigger Interface (CTI) driver"
>> depends on ARM || ARM64
>> help
>> This driver provides support for CoreSight CTI and CTM
> components.
>> @@ -147,6 +147,9 @@ config CORESIGHT_CTI
>> halt compared to disabling sources and sinks normally in
> driver
>> software.
>>
>> + To compile this driver as a module, choose M here: the
>> + module will be called coresight-cti.
>> +
>> config CORESIGHT_CTI_INTEGRATION_REGS
>> bool "Access CTI CoreSight Integration Registers"
>> depends on CORESIGHT_CTI
>> diff --git a/drivers/hwtracing/coresight/Makefile
> b/drivers/hwtracing/coresight/Makefile
>> index 8a7d7ddcce24..c65a153b1e1b 100644
>> --- a/drivers/hwtracing/coresight/Makefile
>> +++ b/drivers/hwtracing/coresight/Makefile
>> @@ -18,6 +18,6 @@ coresight-etm4x-y := coresight-etm4x-core.o
> coresight-etm4x-sysfs.o
>> obj-$(CONFIG_CORESIGHT_STM) += coresight-stm.o
>> obj-$(CONFIG_CORESIGHT_CPU_DEBUG) += coresight-cpu-debug.o
>> obj-$(CONFIG_CORESIGHT_CATU) += coresight-catu.o
>> -obj-$(CONFIG_CORESIGHT_CTI) += coresight-cti.o \
>> - coresight-cti-platform.o \
>> +obj-$(CONFIG_CORESIGHT_CTI) += coresight-cti.o
>> +coresight-cti-y := coresight-cti-core.o
>> coresight-cti-platform.o
> \
>> coresight-cti-sysfs.o
>> diff --git a/drivers/hwtracing/coresight/coresight-cti.c
> b/drivers/hwtracing/coresight/coresight-cti-core.c
>> similarity index 98%
>> rename from drivers/hwtracing/coresight/coresight-cti.c
>> rename to drivers/hwtracing/coresight/coresight-cti-core.c
>> index 2829286daed9..b31839682c9e 100644
>> --- a/drivers/hwtracing/coresight/coresight-cti.c
>> +++ b/drivers/hwtracing/coresight/coresight-cti-core.c
>> @@ -618,6 +618,14 @@ static void cti_device_release(struct device
>> *dev)
>> if (drvdata->csdev_release)
>> drvdata->csdev_release(dev);
>> }
>> +static int __exit cti_remove(struct amba_device *adev)
>> +{
>> + struct cti_drvdata *drvdata = dev_get_drvdata(&adev->dev);
>> +
>> + coresight_unregister(drvdata->csdev);
>> +
>> + return 0;
>> +}
>>
>> static int cti_probe(struct amba_device *adev, const struct amba_id
> *id)
>> {
>> @@ -739,6 +747,7 @@ static const struct amba_id cti_ids[] = {
>> CS_AMBA_UCI_ID(0x000bb9ed, uci_id_cti), /* Coresight CTI (SoC
> 600) */
>> { 0, 0},
>> };
>> +MODULE_DEVICE_TABLE(amba, cti_ids);
>>
>> static struct amba_driver cti_driver = {
>> .drv = {
>> @@ -747,6 +756,7 @@ static struct amba_driver cti_driver = {
>> .suppress_bind_attrs = true,
>> },
>> .probe = cti_probe,
>> + .remove = cti_remove,
>> .id_table = cti_ids,
>> };
>>
>> @@ -769,3 +779,7 @@ static void __exit cti_exit(void)
>>
>> module_init(cti_init);
>> module_exit(cti_exit);
>> +
>> +MODULE_AUTHOR("Mike Leach <mike.leach@linaro.org>");
>> +MODULE_DESCRIPTION("Arm CoreSight Funnel Driver");
>
> Cut and paste error here - this module it the CTI, not the funnel.
>
> Regards
>
> Mike
>
Thanks for catching this Mike. I'll fix it in next patch set.
Thanks,
Tingwei
>> +MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/hwtracing/coresight/coresight-platform.c
> b/drivers/hwtracing/coresight/coresight-platform.c
>> index 43418a2126ff..44f24683f089 100644
>> --- a/drivers/hwtracing/coresight/coresight-platform.c
>> +++ b/drivers/hwtracing/coresight/coresight-platform.c
>> @@ -76,6 +76,7 @@ coresight_find_csdev_by_fwnode(struct fwnode_handle
> *r_fwnode)
>> }
>> return csdev;
>> }
>> +EXPORT_SYMBOL_GPL(coresight_find_csdev_by_fwnode);
>>
>> #ifdef CONFIG_OF
>> static inline bool of_coresight_legacy_ep_is_input(struct device_node
> *ep)
>> diff --git a/drivers/hwtracing/coresight/coresight.c
> b/drivers/hwtracing/coresight/coresight.c
>> index bf8c41901016..cf7079f4b99c 100644
>> --- a/drivers/hwtracing/coresight/coresight.c
>> +++ b/drivers/hwtracing/coresight/coresight.c
>> @@ -273,6 +273,7 @@ void coresight_set_assoc_ectdev_mutex(struct
> coresight_device *csdev,
>> csdev->ect_dev = ect_csdev;
>> mutex_unlock(&coresight_mutex);
>> }
>> +EXPORT_SYMBOL_GPL(coresight_set_assoc_ectdev_mutex);
>>
>> static int coresight_enable_sink(struct coresight_device *csdev,
>> u32 mode, void *data)
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum,
>> a Linux Foundation Collaborative Project
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] md-cluster: fix safemode_delay value when converting to clustered bitmap
From: heming.zhao @ 2020-07-17 3:56 UTC (permalink / raw)
To: NeilBrown, linux-raid; +Cc: neilb, song
In-Reply-To: <87wo33vxqo.fsf@notabene.neil.brown.name>
On 7/17/20 7:36 AM, NeilBrown wrote:
> On Thu, Jul 16 2020, Zhao Heming wrote:
>
>> When array convert to clustered bitmap, the safe_mode_delay doesn't clean and vice versa.
>> the /sys/block/mdX/md/safe_mode_delay keep original value after changing bitmap type.
... ...
>> }
>> mddev_suspend(mddev);
>> md_bitmap_destroy(mddev);
>> @@ -8366,6 +8369,7 @@ int md_setup_cluster(struct mddev *mddev, int nodes)
>> }
>> spin_unlock(&pers_lock);
>>
>> + mddev->safemode_delay = 0;
>> return md_cluster_ops->join(mddev, nodes);
>
> ->join can fail.
> I'd rather you checked the error there, and only clear safemode_delay if
> the return value is zero.
>
> NeilBrown
>
accept, I was aware of this issue after I sent the patch.
the md_cluster_stop() looks a good place to do the clear job.
md_bitmap_read_sb will call md_cluster_stop when md_setup_cluster return error.
I will send patch v3 after I finish test.
btw,
with investigation safemode_delay bug, I found there is another bug with cluster-md:
md_cluster module can't rmmod in some condition.
below test using original SUSE leap15.2 kernel (5.3.18-xx)
```
node1 # mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb
mdadm: array /dev/md0 started.
node1 # lsmod | egrep "raid|md_"
md_cluster 28672 1
raid1 53248 1
md_mod 176128 2 raid1,md_cluster
dlm 212992 14 md_cluster
node1 # mdadm -S --scan
node1 # lsmod | egrep "raid|md_"
md_cluster 28672 0
raid1 53248 0
md_mod 176128 2 raid1,md_cluster
dlm 212992 9 md_cluster <=== looks cluster-md holds sth, but md_cluster can rmmod now.
node1 # mdadm --zero-superblock /dev/sd{a,b}
node1 # mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb
node1 # mdadm -G /dev/md0 -b none
node1 # lsmod | egrep "raid|md_"
md_cluster 28672 1
raid1 53248 1
md_mod 176128 2 raid1,md_cluster
dlm 212992 9 md_cluster
node1 # mdadm -S --scan
node1 # lsmod | egrep "raid|md_"
md_cluster 28672 1 <=== something still live
raid1 53248 0
md_mod 176128 2 raid1,md_cluster
dlm 212992 9 md_cluster
```
I plan to fix this rmmod bug after I fixing mdadm show active issue.
>
>> }
>>
>> --
>> 1.8.3.1
^ permalink raw reply
* Re: [PATCH v2 00/20] coresight: allow to build coresight as modules
From: tingwei @ 2020-07-17 3:53 UTC (permalink / raw)
To: Mike Leach
Cc: tsoni, Sai Prakash Ranjan, Kim Phillips, Mathieu Poirier,
Suzuki K Poulose, Alexander Shishkin, Greg Kroah-Hartman,
Coresight ML, Mao Jinlong, Mian Yousaf Kaukab, Russell King,
Randy Dunlap, linux-arm-kernel, linux-arm-kernel
In-Reply-To: <CAJ9a7Vi04NaqVmQCo0vxpRiC+9GXrsm3-EkTwL32h_5W3bvCBw@mail.gmail.com>
On 2020-07-16 21:29, Mike Leach wrote:
> Hi,
>
> I've tried to apply this set locally to test functionality but patch
> 03 does not apply without --3way, and patch 11 does not apply at all.
> I am attempting to apply to 5.8-rc5. What does this set apply to?
>
It's applied on 5.7.8. I'll rebase to 5.8-rc5 and push a new patchset.
Thanks,
Tingwei
> Thanks
>
> Mike
>
> On Tue, 14 Jul 2020 at 06:49, Tingwei Zhang <tingwei@codeaurora.org>
> wrote:
>>
>> Allow to build coresight as modules. This gives developers the
> feasibility to
>> test their code without reboot.
>>
>> This series is based on below two series.
>>
>> - "coresight: allow to build components as modules"
>> https://lkml.org/lkml/2018/6/5/989
>> - "coresight: make drivers modular"
>> https://lkml.org/lkml/2020/1/17/468
>>
>> Change from v1:
>> Use try_module_get() to avoid module to be unloaded when device is
>> used
>> in active trace session. (Mathieu P)
>>
>> Change from above two series.
>> This series adds the support to dynamically remove module when the
> device in
>> that module is enabled and used by some trace path. It disables all
> trace
>> paths with that device and release the trace path.
>>
>> Kim Phillips (7):
>> coresight: use IS_ENABLED for CONFIGs that may be modules
>> coresight: allow etm3x to be built as a module
>> coresight: allow etm4x to be built as a module
>> coresight: allow etb to be built as a module
>> coresight: allow tpiu to be built as a module
>> coresight: allow tmc to be built as a module
>> coresight: allow funnel and replicator drivers to be built as
>> modules
>>
>> Mian Yousaf Kaukab (4):
>> coresight: export global symbols
>> coresight: remove multiple init calls from funnel driver
>> coresight: remove multiple init calls from replicator driver
>> coresight: tmc-etr: add function to register catu ops
>>
>> Tingwei Zhang (9):
>> coresight: cpu_debug: add module name in Kconfig
>> coresight: cpu_debug: define MODULE_DEVICE_TABLE
>> coresight: add coresight prefix to barrier_pkt
>> Allow to build coresight-stm as a module, for ease of development.
>> coresight: cti: add function to register cti associate ops
>> coresight: allow cti to be built as a module
>> coresight: allow catu drivers to be built as modules
>> coresight: add try_get_module() in coresight_grab_device()
>> coresight: allow the coresight core driver to be built as a module
>>
>> drivers/hwtracing/coresight/Kconfig | 54 ++++++++--
>> drivers/hwtracing/coresight/Makefile | 20 ++--
>> drivers/hwtracing/coresight/coresight-catu.c | 37 ++++++-
>> drivers/hwtracing/coresight/coresight-catu.h | 2 -
>> .../{coresight.c => coresight-core.c} | 101
>> +++++++++++++++---
>> .../hwtracing/coresight/coresight-cpu-debug.c | 2 +
>> .../{coresight-cti.c => coresight-cti-core.c} | 46 +++++++-
>> drivers/hwtracing/coresight/coresight-etb10.c | 22 +++-
>> .../hwtracing/coresight/coresight-etm-perf.c | 9 +-
>> .../hwtracing/coresight/coresight-etm-perf.h | 5 +-
>> ...resight-etm3x.c => coresight-etm3x-core.c} | 27 ++++-
>> ...resight-etm4x.c => coresight-etm4x-core.c} | 31 +++++-
>> .../hwtracing/coresight/coresight-funnel.c | 62 ++++++++++-
>> .../hwtracing/coresight/coresight-platform.c | 1 +
>> drivers/hwtracing/coresight/coresight-priv.h | 24 ++---
>> .../coresight/coresight-replicator.c | 63 ++++++++++-
>> drivers/hwtracing/coresight/coresight-stm.c | 20 +++-
>> .../{coresight-tmc.c => coresight-tmc-core.c} | 19 +++-
>> .../hwtracing/coresight/coresight-tmc-etf.c | 2 +-
>> .../hwtracing/coresight/coresight-tmc-etr.c | 21 +++-
>> drivers/hwtracing/coresight/coresight-tmc.h | 3 +
>> drivers/hwtracing/coresight/coresight-tpiu.c | 19 +++-
>> include/linux/coresight.h | 2 +-
>> 23 files changed, 518 insertions(+), 74 deletions(-)
>> rename drivers/hwtracing/coresight/{coresight.c => coresight-core.c}
> (94%)
>> rename drivers/hwtracing/coresight/{coresight-cti.c =>
> coresight-cti-core.c} (95%)
>> rename drivers/hwtracing/coresight/{coresight-etm3x.c =>
> coresight-etm3x-core.c} (97%)
>> rename drivers/hwtracing/coresight/{coresight-etm4x.c =>
> coresight-etm4x-core.c} (98%)
>> rename drivers/hwtracing/coresight/{coresight-tmc.c =>
> coresight-tmc-core.c} (96%)
>>
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> Forum,
>> a Linux Foundation Collaborative Project
>>
>> _______________________________________________
>> CoreSight mailing list
>> CoreSight@lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/coresight
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [virtio-dev] [RFC for Linux v4 0/2] virtio_balloon: Add VIRTIO_BALLOON_F_CONT_PAGES to report continuous pages
From: teawater @ 2020-07-17 3:52 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Andrea Arcangeli, virtio-dev, David Hildenbrand, qemu-devel,
Jason Wang, linux-kernel, virtualization, linux-mm, Andrew Morton,
Hui Zhu
In-Reply-To: <20200716064340-mutt-send-email-mst@kernel.org>
> 2020年7月16日 18:45，Michael S. Tsirkin <mst@redhat.com> 写道：
>
> On Thu, Jul 16, 2020 at 03:01:18PM +0800, teawater wrote:
>>
>>
>>> 2020年7月16日 14:38，Michael S. Tsirkin <mst@redhat.com> 写道：
>>>
>>> On Thu, Jul 16, 2020 at 10:41:50AM +0800, Hui Zhu wrote:
>>>> The first, second and third version are in [1], [2] and [3].
>>>> Code of current version for Linux and qemu is available in [4] and [5].
>>>> Update of this version:
>>>> 1. Report continuous pages will increase the speed. So added deflate
>>>> continuous pages.
>>>> 2. According to the comments from David in [6], added 2 new vqs inflate_cont_vq
>>>> and deflate_cont_vq to report continuous pages with format 32 bits pfn and 32
>>>> bits size.
>>>> Following is the introduction of the function.
>>>> These patches add VIRTIO_BALLOON_F_CONT_PAGES to virtio_balloon. With this
>>>> flag, balloon tries to use continuous pages to inflate and deflate.
>>>> Opening this flag can bring two benefits:
>>>> 1. Report continuous pages will increase memory report size of each time
>>>> call tell_host. Then it will increase the speed of balloon inflate and
>>>> deflate.
>>>> 2. Host THPs will be splitted when qemu release the page of balloon inflate.
>>>> Inflate balloon with continuous pages will let QEMU release the pages
>>>> of same THPs. That will help decrease the splitted THPs number in
>>>> the host.
>>>> Following is an example in a VM with 1G memory 1CPU. This test setups an
>>>> environment that has a lot of fragmentation pages. Then inflate balloon will
>>>> split the THPs.
>>
>>
>>>> // This is the THP number before VM execution in the host.
>>>> // None use THP.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 0 kB
>> These lines are from host.
>>
>>>> // After VM start, use usemem
>>>> // (https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git)
>>>> // punch-holes function generates 400m fragmentation pages in the guest
>>>> // kernel.
>>>> usemem --punch-holes -s -1 800m &
>> These lines are from guest. They setups the environment that has a lot of fragmentation pages.
>>
>>>> // This is the THP number after this command in the host.
>>>> // Some THP is used by VM because usemem will access 800M memory
>>>> // in the guest.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 911360 kB
>> These lines are from host.
>>
>>>> // Connect to the QEMU monitor, setup balloon, and set it size to 600M.
>>>> (qemu) device_add virtio-balloon-pci,id=balloon1
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>>>> (qemu) balloon 600
>>>> (qemu) info balloon
>>>> balloon: actual=600
>> These lines are from host.
>>
>>>> // This is the THP number after inflate the balloon in the host.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 88064 kB
>> These lines are from host.
>>
>>>> // Set the size back to 1024M in the QEMU monitor.
>>>> (qemu) balloon 1024
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>> These lines are from host.
>>
>>>> // Use usemem to increase the memory usage of QEMU.
>>>> killall usemem
>>>> usemem 800m
>> These lines are from guest.
>>
>>>> // This is the THP number after this operation.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 65536 kB
>> These lines are from host.
>>
>>
>>
>>>>
>>>> Following example change to use continuous pages balloon. The number of
>>>> splitted THPs is decreased.
>>>> // This is the THP number before VM execution in the host.
>>>> // None use THP.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 0 kB
>> These lines are from host.
>>
>>>> // After VM start, use usemem punch-holes function generates 400M
>>>> // fragmentation pages in the guest kernel.
>>>> usemem --punch-holes -s -1 800m &
>> These lines are from guest. They setups the environment that has a lot of fragmentation pages.
>>
>>>> // This is the THP number after this command in the host.
>>>> // Some THP is used by VM because usemem will access 800M memory
>>>> // in the guest.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 911360 kB
>> These lines are from host.
>>
>>>> // Connect to the QEMU monitor, setup balloon, and set it size to 600M.
>>>> (qemu) device_add virtio-balloon-pci,id=balloon1,cont-pages=on
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>>>> (qemu) balloon 600
>>>> (qemu) info balloon
>>>> balloon: actual=600
>> These lines are from host.
>>
>>>> // This is the THP number after inflate the balloon in the host.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 616448 kB
>>>> // Set the size back to 1024M in the QEMU monitor.
>>>> (qemu) balloon 1024
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>> These lines are from host.
>>
>>>> // Use usemem to increase the memory usage of QEMU.
>>>> killall usemem
>>>> usemem 800m
>> These lines are from guest.
>>
>>>> // This is the THP number after this operation.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 907264 kB
>> These lines are from host.
>>
>>>
>>> I'm a bit confused about which of the above run within guest,
>>> and which run within host. Could you explain pls?
>>>
>>>
>>
>> I added some introduction to show where these lines is get from.
>>
>> Best,
>> Hui
>
>
> OK so we see host has more free THPs. But guest has presumably less now - so
> the total page table depth is the same. Did we gain anything?
>
cat /proc/meminfo | grep AnonHugePages:
This command will output how many THPs is used by current system.
There is no program using THPs except qemu.
So this command will show how many THPs is used by qemu.
The last outout of “cat /proc/meminfo | grep AnonHugePages:” show how many THPs is used by qemu when this 2 qemu’s anon page number is same.
Without “cont-pages=on”, qemu keep 65536kb THPs.
Wiht “cont-pages=on”, qemu keep 907264kb THPs.
Keep more THPs will make memory access speed high.
This is a test record use this 1G 1 cpu qemu after the fragmentation balloon test:
Without “cont-pages=on”, qemu keep 81920kB THPs.
/ # usemem 800m
943718400 bytes / 489412 usecs = 1883076 KB/s
18725 usecs to free memory
/ # usemem 800m
943718400 bytes / 487070 usecs = 1892130 KB/s
18913 usecs to free memory
/ # usemem 800m
943718400 bytes / 484234 usecs = 1903212 KB/s
18538 usecs to free memory
/ # usemem 800m
943718400 bytes / 486568 usecs = 1894082 KB/s
18982 usecs to free memory
With “cont-pages=on”, qemu keep 907264kb THPs.
/ # usemem 800m
943718400 bytes / 479098 usecs = 1923614 KB/s
18980 usecs to free memory
/ # usemem 800m
943718400 bytes / 477433 usecs = 1930323 KB/s
18562 usecs to free memory
/ # usemem 800m
943718400 bytes / 479790 usecs = 1920840 KB/s
18663 usecs to free memory
/ # usemem 800m
943718400 bytes / 480253 usecs = 1918988 KB/s
19011 usecs to free memory
Best,
Hui
>>
>>>
>>>> [1] https://lkml.org/lkml/2020/3/12/144
>>>> [2] https://lore.kernel.org/linux-mm/1584893097-12317-1-git-send-email-teawater@gmail.com/
>>>> [3] https://lkml.org/lkml/2020/5/12/324
>>>> [4] https://github.com/teawater/linux/tree/balloon_conts
>>>> [5] https://github.com/teawater/qemu/tree/balloon_conts
>>>> [6] https://lkml.org/lkml/2020/5/13/1211
>>>>
>>>> Hui Zhu (2):
>>>> virtio_balloon: Add VIRTIO_BALLOON_F_CONT_PAGES and inflate_cont_vq
>>>> virtio_balloon: Add deflate_cont_vq to deflate continuous pages
>>>>
>>>> drivers/virtio/virtio_balloon.c | 180 +++++++++++++++++++++++++++++++-----
>>>> include/linux/balloon_compaction.h | 12 ++
>>>> include/uapi/linux/virtio_balloon.h | 1
>>>> mm/balloon_compaction.c | 117 +++++++++++++++++++++--
>>>> 4 files changed, 280 insertions(+), 30 deletions(-)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply
* Re: [virtio-dev] [RFC for Linux v4 0/2] virtio_balloon: Add VIRTIO_BALLOON_F_CONT_PAGES to report continuous pages
From: teawater @ 2020-07-17 3:52 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Hui Zhu, David Hildenbrand, Jason Wang, Andrew Morton,
virtualization, linux-kernel, linux-mm, qemu-devel, virtio-dev,
Andrea Arcangeli
In-Reply-To: <20200716064340-mutt-send-email-mst@kernel.org>
> 2020年7月16日 18:45，Michael S. Tsirkin <mst@redhat.com> 写道：
>
> On Thu, Jul 16, 2020 at 03:01:18PM +0800, teawater wrote:
>>
>>
>>> 2020年7月16日 14:38，Michael S. Tsirkin <mst@redhat.com> 写道：
>>>
>>> On Thu, Jul 16, 2020 at 10:41:50AM +0800, Hui Zhu wrote:
>>>> The first, second and third version are in [1], [2] and [3].
>>>> Code of current version for Linux and qemu is available in [4] and [5].
>>>> Update of this version:
>>>> 1. Report continuous pages will increase the speed. So added deflate
>>>> continuous pages.
>>>> 2. According to the comments from David in [6], added 2 new vqs inflate_cont_vq
>>>> and deflate_cont_vq to report continuous pages with format 32 bits pfn and 32
>>>> bits size.
>>>> Following is the introduction of the function.
>>>> These patches add VIRTIO_BALLOON_F_CONT_PAGES to virtio_balloon. With this
>>>> flag, balloon tries to use continuous pages to inflate and deflate.
>>>> Opening this flag can bring two benefits:
>>>> 1. Report continuous pages will increase memory report size of each time
>>>> call tell_host. Then it will increase the speed of balloon inflate and
>>>> deflate.
>>>> 2. Host THPs will be splitted when qemu release the page of balloon inflate.
>>>> Inflate balloon with continuous pages will let QEMU release the pages
>>>> of same THPs. That will help decrease the splitted THPs number in
>>>> the host.
>>>> Following is an example in a VM with 1G memory 1CPU. This test setups an
>>>> environment that has a lot of fragmentation pages. Then inflate balloon will
>>>> split the THPs.
>>
>>
>>>> // This is the THP number before VM execution in the host.
>>>> // None use THP.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 0 kB
>> These lines are from host.
>>
>>>> // After VM start, use usemem
>>>> // (https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git)
>>>> // punch-holes function generates 400m fragmentation pages in the guest
>>>> // kernel.
>>>> usemem --punch-holes -s -1 800m &
>> These lines are from guest. They setups the environment that has a lot of fragmentation pages.
>>
>>>> // This is the THP number after this command in the host.
>>>> // Some THP is used by VM because usemem will access 800M memory
>>>> // in the guest.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 911360 kB
>> These lines are from host.
>>
>>>> // Connect to the QEMU monitor, setup balloon, and set it size to 600M.
>>>> (qemu) device_add virtio-balloon-pci,id=balloon1
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>>>> (qemu) balloon 600
>>>> (qemu) info balloon
>>>> balloon: actual=600
>> These lines are from host.
>>
>>>> // This is the THP number after inflate the balloon in the host.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 88064 kB
>> These lines are from host.
>>
>>>> // Set the size back to 1024M in the QEMU monitor.
>>>> (qemu) balloon 1024
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>> These lines are from host.
>>
>>>> // Use usemem to increase the memory usage of QEMU.
>>>> killall usemem
>>>> usemem 800m
>> These lines are from guest.
>>
>>>> // This is the THP number after this operation.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 65536 kB
>> These lines are from host.
>>
>>
>>
>>>>
>>>> Following example change to use continuous pages balloon. The number of
>>>> splitted THPs is decreased.
>>>> // This is the THP number before VM execution in the host.
>>>> // None use THP.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 0 kB
>> These lines are from host.
>>
>>>> // After VM start, use usemem punch-holes function generates 400M
>>>> // fragmentation pages in the guest kernel.
>>>> usemem --punch-holes -s -1 800m &
>> These lines are from guest. They setups the environment that has a lot of fragmentation pages.
>>
>>>> // This is the THP number after this command in the host.
>>>> // Some THP is used by VM because usemem will access 800M memory
>>>> // in the guest.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 911360 kB
>> These lines are from host.
>>
>>>> // Connect to the QEMU monitor, setup balloon, and set it size to 600M.
>>>> (qemu) device_add virtio-balloon-pci,id=balloon1,cont-pages=on
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>>>> (qemu) balloon 600
>>>> (qemu) info balloon
>>>> balloon: actual=600
>> These lines are from host.
>>
>>>> // This is the THP number after inflate the balloon in the host.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 616448 kB
>>>> // Set the size back to 1024M in the QEMU monitor.
>>>> (qemu) balloon 1024
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>> These lines are from host.
>>
>>>> // Use usemem to increase the memory usage of QEMU.
>>>> killall usemem
>>>> usemem 800m
>> These lines are from guest.
>>
>>>> // This is the THP number after this operation.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 907264 kB
>> These lines are from host.
>>
>>>
>>> I'm a bit confused about which of the above run within guest,
>>> and which run within host. Could you explain pls?
>>>
>>>
>>
>> I added some introduction to show where these lines is get from.
>>
>> Best,
>> Hui
>
>
> OK so we see host has more free THPs. But guest has presumably less now - so
> the total page table depth is the same. Did we gain anything?
>
cat /proc/meminfo | grep AnonHugePages:
This command will output how many THPs is used by current system.
There is no program using THPs except qemu.
So this command will show how many THPs is used by qemu.
The last outout of “cat /proc/meminfo | grep AnonHugePages:” show how many THPs is used by qemu when this 2 qemu’s anon page number is same.
Without “cont-pages=on”, qemu keep 65536kb THPs.
Wiht “cont-pages=on”, qemu keep 907264kb THPs.
Keep more THPs will make memory access speed high.
This is a test record use this 1G 1 cpu qemu after the fragmentation balloon test:
Without “cont-pages=on”, qemu keep 81920kB THPs.
/ # usemem 800m
943718400 bytes / 489412 usecs = 1883076 KB/s
18725 usecs to free memory
/ # usemem 800m
943718400 bytes / 487070 usecs = 1892130 KB/s
18913 usecs to free memory
/ # usemem 800m
943718400 bytes / 484234 usecs = 1903212 KB/s
18538 usecs to free memory
/ # usemem 800m
943718400 bytes / 486568 usecs = 1894082 KB/s
18982 usecs to free memory
With “cont-pages=on”, qemu keep 907264kb THPs.
/ # usemem 800m
943718400 bytes / 479098 usecs = 1923614 KB/s
18980 usecs to free memory
/ # usemem 800m
943718400 bytes / 477433 usecs = 1930323 KB/s
18562 usecs to free memory
/ # usemem 800m
943718400 bytes / 479790 usecs = 1920840 KB/s
18663 usecs to free memory
/ # usemem 800m
943718400 bytes / 480253 usecs = 1918988 KB/s
19011 usecs to free memory
Best,
Hui
>>
>>>
>>>> [1] https://lkml.org/lkml/2020/3/12/144
>>>> [2] https://lore.kernel.org/linux-mm/1584893097-12317-1-git-send-email-teawater@gmail.com/
>>>> [3] https://lkml.org/lkml/2020/5/12/324
>>>> [4] https://github.com/teawater/linux/tree/balloon_conts
>>>> [5] https://github.com/teawater/qemu/tree/balloon_conts
>>>> [6] https://lkml.org/lkml/2020/5/13/1211
>>>>
>>>> Hui Zhu (2):
>>>> virtio_balloon: Add VIRTIO_BALLOON_F_CONT_PAGES and inflate_cont_vq
>>>> virtio_balloon: Add deflate_cont_vq to deflate continuous pages
>>>>
>>>> drivers/virtio/virtio_balloon.c | 180 +++++++++++++++++++++++++++++++-----
>>>> include/linux/balloon_compaction.h | 12 ++
>>>> include/uapi/linux/virtio_balloon.h | 1
>>>> mm/balloon_compaction.c | 117 +++++++++++++++++++++--
>>>> 4 files changed, 280 insertions(+), 30 deletions(-)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply
* Re: [virtio-dev] [RFC for Linux v4 0/2] virtio_balloon: Add VIRTIO_BALLOON_F_CONT_PAGES to report continuous pages
From: teawater @ 2020-07-17 3:52 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Hui Zhu, David Hildenbrand, Jason Wang, Andrew Morton,
virtualization, linux-kernel, linux-mm, qemu-devel, virtio-dev,
Andrea Arcangeli
In-Reply-To: <20200716064340-mutt-send-email-mst@kernel.org>
> 2020年7月16日 18:45，Michael S. Tsirkin <mst@redhat.com> 写道：
>
> On Thu, Jul 16, 2020 at 03:01:18PM +0800, teawater wrote:
>>
>>
>>> 2020年7月16日 14:38，Michael S. Tsirkin <mst@redhat.com> 写道：
>>>
>>> On Thu, Jul 16, 2020 at 10:41:50AM +0800, Hui Zhu wrote:
>>>> The first, second and third version are in [1], [2] and [3].
>>>> Code of current version for Linux and qemu is available in [4] and [5].
>>>> Update of this version:
>>>> 1. Report continuous pages will increase the speed. So added deflate
>>>> continuous pages.
>>>> 2. According to the comments from David in [6], added 2 new vqs inflate_cont_vq
>>>> and deflate_cont_vq to report continuous pages with format 32 bits pfn and 32
>>>> bits size.
>>>> Following is the introduction of the function.
>>>> These patches add VIRTIO_BALLOON_F_CONT_PAGES to virtio_balloon. With this
>>>> flag, balloon tries to use continuous pages to inflate and deflate.
>>>> Opening this flag can bring two benefits:
>>>> 1. Report continuous pages will increase memory report size of each time
>>>> call tell_host. Then it will increase the speed of balloon inflate and
>>>> deflate.
>>>> 2. Host THPs will be splitted when qemu release the page of balloon inflate.
>>>> Inflate balloon with continuous pages will let QEMU release the pages
>>>> of same THPs. That will help decrease the splitted THPs number in
>>>> the host.
>>>> Following is an example in a VM with 1G memory 1CPU. This test setups an
>>>> environment that has a lot of fragmentation pages. Then inflate balloon will
>>>> split the THPs.
>>
>>
>>>> // This is the THP number before VM execution in the host.
>>>> // None use THP.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 0 kB
>> These lines are from host.
>>
>>>> // After VM start, use usemem
>>>> // (https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git)
>>>> // punch-holes function generates 400m fragmentation pages in the guest
>>>> // kernel.
>>>> usemem --punch-holes -s -1 800m &
>> These lines are from guest. They setups the environment that has a lot of fragmentation pages.
>>
>>>> // This is the THP number after this command in the host.
>>>> // Some THP is used by VM because usemem will access 800M memory
>>>> // in the guest.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 911360 kB
>> These lines are from host.
>>
>>>> // Connect to the QEMU monitor, setup balloon, and set it size to 600M.
>>>> (qemu) device_add virtio-balloon-pci,id=balloon1
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>>>> (qemu) balloon 600
>>>> (qemu) info balloon
>>>> balloon: actual=600
>> These lines are from host.
>>
>>>> // This is the THP number after inflate the balloon in the host.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 88064 kB
>> These lines are from host.
>>
>>>> // Set the size back to 1024M in the QEMU monitor.
>>>> (qemu) balloon 1024
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>> These lines are from host.
>>
>>>> // Use usemem to increase the memory usage of QEMU.
>>>> killall usemem
>>>> usemem 800m
>> These lines are from guest.
>>
>>>> // This is the THP number after this operation.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 65536 kB
>> These lines are from host.
>>
>>
>>
>>>>
>>>> Following example change to use continuous pages balloon. The number of
>>>> splitted THPs is decreased.
>>>> // This is the THP number before VM execution in the host.
>>>> // None use THP.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 0 kB
>> These lines are from host.
>>
>>>> // After VM start, use usemem punch-holes function generates 400M
>>>> // fragmentation pages in the guest kernel.
>>>> usemem --punch-holes -s -1 800m &
>> These lines are from guest. They setups the environment that has a lot of fragmentation pages.
>>
>>>> // This is the THP number after this command in the host.
>>>> // Some THP is used by VM because usemem will access 800M memory
>>>> // in the guest.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 911360 kB
>> These lines are from host.
>>
>>>> // Connect to the QEMU monitor, setup balloon, and set it size to 600M.
>>>> (qemu) device_add virtio-balloon-pci,id=balloon1,cont-pages=on
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>>>> (qemu) balloon 600
>>>> (qemu) info balloon
>>>> balloon: actual=600
>> These lines are from host.
>>
>>>> // This is the THP number after inflate the balloon in the host.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 616448 kB
>>>> // Set the size back to 1024M in the QEMU monitor.
>>>> (qemu) balloon 1024
>>>> (qemu) info balloon
>>>> balloon: actual=1024
>> These lines are from host.
>>
>>>> // Use usemem to increase the memory usage of QEMU.
>>>> killall usemem
>>>> usemem 800m
>> These lines are from guest.
>>
>>>> // This is the THP number after this operation.
>>>> cat /proc/meminfo | grep AnonHugePages:
>>>> AnonHugePages: 907264 kB
>> These lines are from host.
>>
>>>
>>> I'm a bit confused about which of the above run within guest,
>>> and which run within host. Could you explain pls?
>>>
>>>
>>
>> I added some introduction to show where these lines is get from.
>>
>> Best,
>> Hui
>
>
> OK so we see host has more free THPs. But guest has presumably less now - so
> the total page table depth is the same. Did we gain anything?
>
cat /proc/meminfo | grep AnonHugePages:
This command will output how many THPs is used by current system.
There is no program using THPs except qemu.
So this command will show how many THPs is used by qemu.
The last outout of “cat /proc/meminfo | grep AnonHugePages:” show how many THPs is used by qemu when this 2 qemu’s anon page number is same.
Without “cont-pages=on”, qemu keep 65536kb THPs.
Wiht “cont-pages=on”, qemu keep 907264kb THPs.
Keep more THPs will make memory access speed high.
This is a test record use this 1G 1 cpu qemu after the fragmentation balloon test:
Without “cont-pages=on”, qemu keep 81920kB THPs.
/ # usemem 800m
943718400 bytes / 489412 usecs = 1883076 KB/s
18725 usecs to free memory
/ # usemem 800m
943718400 bytes / 487070 usecs = 1892130 KB/s
18913 usecs to free memory
/ # usemem 800m
943718400 bytes / 484234 usecs = 1903212 KB/s
18538 usecs to free memory
/ # usemem 800m
943718400 bytes / 486568 usecs = 1894082 KB/s
18982 usecs to free memory
With “cont-pages=on”, qemu keep 907264kb THPs.
/ # usemem 800m
943718400 bytes / 479098 usecs = 1923614 KB/s
18980 usecs to free memory
/ # usemem 800m
943718400 bytes / 477433 usecs = 1930323 KB/s
18562 usecs to free memory
/ # usemem 800m
943718400 bytes / 479790 usecs = 1920840 KB/s
18663 usecs to free memory
/ # usemem 800m
943718400 bytes / 480253 usecs = 1918988 KB/s
19011 usecs to free memory
Best,
Hui
>>
>>>
>>>> [1] https://lkml.org/lkml/2020/3/12/144
>>>> [2] https://lore.kernel.org/linux-mm/1584893097-12317-1-git-send-email-teawater@gmail.com/
>>>> [3] https://lkml.org/lkml/2020/5/12/324
>>>> [4] https://github.com/teawater/linux/tree/balloon_conts
>>>> [5] https://github.com/teawater/qemu/tree/balloon_conts
>>>> [6] https://lkml.org/lkml/2020/5/13/1211
>>>>
>>>> Hui Zhu (2):
>>>> virtio_balloon: Add VIRTIO_BALLOON_F_CONT_PAGES and inflate_cont_vq
>>>> virtio_balloon: Add deflate_cont_vq to deflate continuous pages
>>>>
>>>> drivers/virtio/virtio_balloon.c | 180 +++++++++++++++++++++++++++++++-----
>>>> include/linux/balloon_compaction.h | 12 ++
>>>> include/uapi/linux/virtio_balloon.h | 1
>>>> mm/balloon_compaction.c | 117 +++++++++++++++++++++--
>>>> 4 files changed, 280 insertions(+), 30 deletions(-)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply
* Re: [PATCH -next] rsxx: Convert to DEFINE_SHOW_ATTRIBUTE
From: miaoqinglang @ 2020-07-17 3:51 UTC (permalink / raw)
To: Jens Axboe, Greg Kroah-Hartman, Joshua Morris, Philip Kelleher
Cc: linux-block, linux-kernel
In-Reply-To: <87a5f046-e77b-af25-6656-c8b075a16edf@kernel.dk>
在 2020/7/17 10:16, Jens Axboe 写道:
> On 7/16/20 7:37 PM, miaoqinglang wrote:
>>
>> 在 2020/7/16 23:45, Jens Axboe 写道:
>>> On 7/16/20 3:04 AM, Qinglang Miao wrote:
>>>> From: Liu Shixin <liushixin2@huawei.com>
>>>>
>>>> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>>> None of these apply against the 5.9 block tree, looks like some
>>> read -> read_iter conversion has happened in another branch that
>>> I'm not privy to.
>>
>> Hi Jens,
>>
>> Sorry I didn't mention it in commit log, but this patch is based
>> on linux-next where commit <4d4901c6d7> has switched over direct
>> seq_read method calls to seq_read_iter, this is why there's conflict in
>> your apply.
>>
>> Do you think I should send a new patch based on 5.8rc?
>
> That'll just create a needless conflict. But I don't even know what tree
> is carrying the patch that changes it to use seq_read_iter, so hard to
> make other suggestions.
This patch is against linux-next, which is ahead of both
linux-block and mainline tree. Here's the interlinkage:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/4d4901c6d748efab8aab6e7d2405dadaed0bea50](javascript:;)
or you can find the commit <4d4901c6d7> which changes seq_read to
seq_read_iter with the -next tag, in fact, it's just a simple script:
sed -i -e 's/\.read\(\s*=\s*\)seq_read/\.read_iter\1seq_read_iter/g'
By the way, there won't be needless confict because seq_read in both
file and macro are switched to seq_read_iter together.
>
> Alternatively, I can hang on to them until the other change hits
> mainline, and then queue them up after that.
>
That looks good to me. Let me know if patch based on 5.8rc is needed.
Thanks.
Qinglang
.
^ permalink raw reply
* PROBLEM: [e1000e] 10% throughput drop on I219-LM after the buffer overrun fix even with TSO&GSO disabled
From: qianshangshu.1997 @ 2020-07-17 3:50 UTC (permalink / raw)
To: jeffrey.t.kirsher, davem; +Cc: intel-wired-lan, netdev, linux-kernel
In-Reply-To: <SJ0PR07MB7584416FB7A07FD506B8237F9C7C0@SJ0PR07MB7584.namprd07.prod.outlook.com>
[1.] One line summary of the problem:
[e1000e] 10% throughput drop on I219-LM after the buffer overrun fix even
with TSO&GSO disabled
[2.] Full description of the problem/report:
With e1000e 3.6.2-k and 3.8.4-NAPI driver, which include the fix for the
buffer overrun problem
(https://github.com/torvalds/linux/commit/b10effb92e272051dd1ec0d7be56bf9ca8
5ab927, discussion: https://www.spinics.net/lists/netdev/msg460589.html),
I219-LM network card have a 10% throughput drop in the iperf3 test (with TSO
and GSO disabled) compared with the driver without such patch, and the
client is initiating the stream in such test (iperf3 client mode without -R
option). If the server is initiating the stream (with -R option in iperf3
client mode), the performance is not impacted.
That is to say, disabling TSO and GSO as suggested in that patch still have
performance impact on the TCP stream, and the throughput drops about 10%.
I tried to rollback the patch introduced to fix the buffer overrun problem
in the 3.8.4-NAPI driver, with TSO and GSO enabled, iperf3 test still cannot
max out my 1Gbps uplink. However, with TSO and GSO disabled, 1Gbps uplink
can be fully saturated.
I'll attach iperf3 test results for all these situations later in this
email.
[3.] Keywords
Network driver, e1000e
[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
Linux version 5.4.0-31-generic (buildd@lgw01-amd64-059) (gcc version 9.3.0
(Ubuntu 9.3.0-10ubuntu2)) #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020
[4.2.] Kernel .config file:
https://kernel.ubuntu.com/~kernel-ppa/config/focal/linux/5.4.0-31.35/amd64-c
onfig.flavour.generic
[5.] Most recent kernel version which did not have the bug:
V4.14.2
[6.] Environment
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
I219-LM (rev 31)
driver: e1000e
version: 3.2.6-k
firmware-version: 0.8-4
expansion-rom-version:
bus-info: 0000:00:1f.6
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
iperf3:
iperf 3.7 (cJSON 1.5.2)
Linux Hetzner 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020
x86_64 Optional features available: CPU affinity setting, IPv6 flow label,
SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing,
authentication
[X.] Other notes, patches, fixes, workarounds:
3.6.2-k w/ TSO & GSO
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 119 MBytes 99.4 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 119 MBytes 99.4 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 119 MBytes 99.4 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 119 MBytes 99.5 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 119 MBytes 99.5 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 601 MBytes 504 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 594 MBytes 497 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 351 MBytes 293 Mbits/sec 134 sender
[ 5] 0.00-10.00 sec 344 MBytes 289 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 204 MBytes 171 Mbits/sec 331 sender
[ 7] 0.00-10.00 sec 201 MBytes 168 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 174 MBytes 146 Mbits/sec 226 sender
[ 9] 0.00-10.00 sec 171 MBytes 144 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 177 MBytes 148 Mbits/sec 226 sender
[ 11] 0.00-10.00 sec 173 MBytes 145 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 164 MBytes 138 Mbits/sec 229 sender
[ 13] 0.00-10.00 sec 161 MBytes 135 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.04 GBytes 896 Mbits/sec 1146
sender
[SUM] 0.00-10.00 sec 1.03 GBytes 881 Mbits/sec
receiver
3.6.2-k w/o TSO & GSO
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 190 MBytes 159 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 188 MBytes 157 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 190 MBytes 160 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 188 MBytes 157 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 191 MBytes 160 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 188 MBytes 158 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 190 MBytes 160 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 188 MBytes 158 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 191 MBytes 160 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 188 MBytes 157 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 953 MBytes 799 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 940 MBytes 787 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 256 MBytes 214 Mbits/sec 128 sender
[ 5] 0.00-10.00 sec 252 MBytes 211 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 238 MBytes 199 Mbits/sec 119 sender
[ 7] 0.00-10.00 sec 234 MBytes 196 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 166 MBytes 139 Mbits/sec 207 sender
[ 9] 0.00-10.00 sec 162 MBytes 136 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 222 MBytes 186 Mbits/sec 316 sender
[ 11] 0.00-10.00 sec 219 MBytes 184 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 225 MBytes 189 Mbits/sec 138 sender
[ 13] 0.00-10.00 sec 222 MBytes 186 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.08 GBytes 927 Mbits/sec 908 sender
[SUM] 0.00-10.00 sec 1.06 GBytes 913 Mbits/sec
receiver
3.8.4-NAPI w/ TSO & GSO
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 120 MBytes 100 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 117 MBytes 97.5 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 115 MBytes 96.4 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 114 MBytes 95.1 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 118 MBytes 98.9 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 117 MBytes 97.6 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 118 MBytes 99.3 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 117 MBytes 97.5 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 118 MBytes 99.3 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 116 MBytes 97.5 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 589 MBytes 494 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 580 MBytes 485 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 289 MBytes 241 Mbits/sec 187 sender
[ 5] 0.00-10.00 sec 282 MBytes 236 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 355 MBytes 297 Mbits/sec 324 sender
[ 7] 0.00-10.00 sec 350 MBytes 293 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 144 MBytes 121 Mbits/sec 239 sender
[ 9] 0.00-10.00 sec 141 MBytes 118 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 136 MBytes 113 Mbits/sec 286 sender
[ 11] 0.00-10.00 sec 133 MBytes 111 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 188 MBytes 157 Mbits/sec 156 sender
[ 13] 0.00-10.00 sec 185 MBytes 155 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.09 GBytes 930 Mbits/sec 1192
sender
[SUM] 0.00-10.00 sec 1.06 GBytes 914 Mbits/sec
receiver
3.8.4-NAPI w/o TSO & GSO
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 194 MBytes 163 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 192 MBytes 160 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 194 MBytes 163 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 192 MBytes 160 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 195 MBytes 163 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 192 MBytes 160 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 195 MBytes 163 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 192 MBytes 160 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 195 MBytes 163 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 192 MBytes 161 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 973 MBytes 816 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 958 MBytes 802 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 499 MBytes 418 Mbits/sec 1208
sender
[ 5] 0.00-10.00 sec 487 MBytes 409 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 149 MBytes 125 Mbits/sec 262 sender
[ 7] 0.00-10.00 sec 146 MBytes 122 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 158 MBytes 132 Mbits/sec 199 sender
[ 9] 0.00-10.00 sec 154 MBytes 129 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 179 MBytes 149 Mbits/sec 209 sender
[ 11] 0.00-10.00 sec 175 MBytes 147 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 128 MBytes 107 Mbits/sec 386 sender
[ 13] 0.00-10.00 sec 125 MBytes 105 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.09 GBytes 931 Mbits/sec 2264
sender
[SUM] 0.00-10.00 sec 1.06 GBytes 912 Mbits/sec
receiver
3.8.4-NAPI w/ TSO & GSO (Without buffer overrun patch)
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 204 MBytes 171 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 201 MBytes 169 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 203 MBytes 170 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 201 MBytes 168 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 205 MBytes 172 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 202 MBytes 169 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 204 MBytes 171 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 201 MBytes 169 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 204 MBytes 171 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 200 MBytes 168 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 1019 MBytes 855 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 1006 MBytes 842 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 281 MBytes 235 Mbits/sec 128 sender
[ 5] 0.00-10.00 sec 277 MBytes 232 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 267 MBytes 223 Mbits/sec 154 sender
[ 7] 0.00-10.00 sec 263 MBytes 221 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 170 MBytes 142 Mbits/sec 154 sender
[ 9] 0.00-10.00 sec 166 MBytes 139 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 161 MBytes 135 Mbits/sec 211 sender
[ 11] 0.00-10.00 sec 158 MBytes 132 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 219 MBytes 183 Mbits/sec 116 sender
[ 13] 0.00-10.00 sec 216 MBytes 181 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.07 GBytes 919 Mbits/sec 763 sender
[SUM] 0.00-10.00 sec 1.05 GBytes 906 Mbits/sec
receiver
3.8.4-NAPI w/o TSO & GSO (Without buffer overrun patch)
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 220 MBytes 184 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 218 MBytes 182 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 220 MBytes 185 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 217 MBytes 182 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 216 MBytes 182 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 213 MBytes 179 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 220 MBytes 185 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 218 MBytes 182 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 221 MBytes 185 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 218 MBytes 182 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 1.07 GBytes 920 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 1.06 GBytes 907 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 259 MBytes 217 Mbits/sec 67 sender
[ 5] 0.00-10.00 sec 255 MBytes 214 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 256 MBytes 214 Mbits/sec 168 sender
[ 7] 0.00-10.00 sec 252 MBytes 212 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 260 MBytes 217 Mbits/sec 189 sender
[ 9] 0.00-10.00 sec 256 MBytes 215 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 165 MBytes 138 Mbits/sec 237 sender
[ 11] 0.00-10.00 sec 161 MBytes 135 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 172 MBytes 144 Mbits/sec 220 sender
[ 13] 0.00-10.00 sec 169 MBytes 142 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.08 GBytes 930 Mbits/sec 881 sender
[SUM] 0.00-10.00 sec 1.07 GBytes 917 Mbits/sec
receiver
^ permalink raw reply
* [Intel-wired-lan] PROBLEM: [e1000e] 10% throughput drop on I219-LM after the buffer overrun fix even with TSO&GSO disabled
From: qianshangshu.1997 @ 2020-07-17 3:50 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <SJ0PR07MB7584416FB7A07FD506B8237F9C7C0@SJ0PR07MB7584.namprd07.prod.outlook.com>
[1.] One line summary of the problem:
[e1000e] 10% throughput drop on I219-LM after the buffer overrun fix even
with TSO&GSO disabled
[2.] Full description of the problem/report:
With e1000e 3.6.2-k and 3.8.4-NAPI driver, which include the fix for the
buffer overrun problem
(https://github.com/torvalds/linux/commit/b10effb92e272051dd1ec0d7be56bf9ca8
5ab927, discussion: https://www.spinics.net/lists/netdev/msg460589.html),
I219-LM network card have a 10% throughput drop in the iperf3 test (with TSO
and GSO disabled) compared with the driver without such patch, and the
client is initiating the stream in such test (iperf3 client mode without -R
option). If the server is initiating the stream (with -R option in iperf3
client mode), the performance is not impacted.
That is to say, disabling TSO and GSO as suggested in that patch still have
performance impact on the TCP stream, and the throughput drops about 10%.
I tried to rollback the patch introduced to fix the buffer overrun problem
in the 3.8.4-NAPI driver, with TSO and GSO enabled, iperf3 test still cannot
max out my 1Gbps uplink. However, with TSO and GSO disabled, 1Gbps uplink
can be fully saturated.
I'll attach iperf3 test results for all these situations later in this
email.
[3.] Keywords
Network driver, e1000e
[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
Linux version 5.4.0-31-generic (buildd at lgw01-amd64-059) (gcc version 9.3.0
(Ubuntu 9.3.0-10ubuntu2)) #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020
[4.2.] Kernel .config file:
https://kernel.ubuntu.com/~kernel-ppa/config/focal/linux/5.4.0-31.35/amd64-c
onfig.flavour.generic
[5.] Most recent kernel version which did not have the bug:
V4.14.2
[6.] Environment
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2)
I219-LM (rev 31)
driver: e1000e
version: 3.2.6-k
firmware-version: 0.8-4
expansion-rom-version:
bus-info: 0000:00:1f.6
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
iperf3:
iperf 3.7 (cJSON 1.5.2)
Linux Hetzner 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020
x86_64 Optional features available: CPU affinity setting, IPv6 flow label,
SCTP, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing,
authentication
[X.] Other notes, patches, fixes, workarounds:
3.6.2-k w/ TSO & GSO
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 119 MBytes 99.4 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 119 MBytes 99.4 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 119 MBytes 99.4 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 119 MBytes 99.5 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 120 MBytes 101 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 119 MBytes 99.5 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 601 MBytes 504 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 594 MBytes 497 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 351 MBytes 293 Mbits/sec 134 sender
[ 5] 0.00-10.00 sec 344 MBytes 289 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 204 MBytes 171 Mbits/sec 331 sender
[ 7] 0.00-10.00 sec 201 MBytes 168 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 174 MBytes 146 Mbits/sec 226 sender
[ 9] 0.00-10.00 sec 171 MBytes 144 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 177 MBytes 148 Mbits/sec 226 sender
[ 11] 0.00-10.00 sec 173 MBytes 145 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 164 MBytes 138 Mbits/sec 229 sender
[ 13] 0.00-10.00 sec 161 MBytes 135 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.04 GBytes 896 Mbits/sec 1146
sender
[SUM] 0.00-10.00 sec 1.03 GBytes 881 Mbits/sec
receiver
3.6.2-k w/o TSO & GSO
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 190 MBytes 159 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 188 MBytes 157 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 190 MBytes 160 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 188 MBytes 157 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 191 MBytes 160 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 188 MBytes 158 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 190 MBytes 160 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 188 MBytes 158 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 191 MBytes 160 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 188 MBytes 157 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 953 MBytes 799 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 940 MBytes 787 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 256 MBytes 214 Mbits/sec 128 sender
[ 5] 0.00-10.00 sec 252 MBytes 211 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 238 MBytes 199 Mbits/sec 119 sender
[ 7] 0.00-10.00 sec 234 MBytes 196 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 166 MBytes 139 Mbits/sec 207 sender
[ 9] 0.00-10.00 sec 162 MBytes 136 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 222 MBytes 186 Mbits/sec 316 sender
[ 11] 0.00-10.00 sec 219 MBytes 184 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 225 MBytes 189 Mbits/sec 138 sender
[ 13] 0.00-10.00 sec 222 MBytes 186 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.08 GBytes 927 Mbits/sec 908 sender
[SUM] 0.00-10.00 sec 1.06 GBytes 913 Mbits/sec
receiver
3.8.4-NAPI w/ TSO & GSO
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 120 MBytes 100 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 117 MBytes 97.5 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 115 MBytes 96.4 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 114 MBytes 95.1 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 118 MBytes 98.9 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 117 MBytes 97.6 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 118 MBytes 99.3 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 117 MBytes 97.5 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 118 MBytes 99.3 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 116 MBytes 97.5 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 589 MBytes 494 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 580 MBytes 485 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 289 MBytes 241 Mbits/sec 187 sender
[ 5] 0.00-10.00 sec 282 MBytes 236 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 355 MBytes 297 Mbits/sec 324 sender
[ 7] 0.00-10.00 sec 350 MBytes 293 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 144 MBytes 121 Mbits/sec 239 sender
[ 9] 0.00-10.00 sec 141 MBytes 118 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 136 MBytes 113 Mbits/sec 286 sender
[ 11] 0.00-10.00 sec 133 MBytes 111 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 188 MBytes 157 Mbits/sec 156 sender
[ 13] 0.00-10.00 sec 185 MBytes 155 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.09 GBytes 930 Mbits/sec 1192
sender
[SUM] 0.00-10.00 sec 1.06 GBytes 914 Mbits/sec
receiver
3.8.4-NAPI w/o TSO & GSO
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 194 MBytes 163 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 192 MBytes 160 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 194 MBytes 163 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 192 MBytes 160 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 195 MBytes 163 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 192 MBytes 160 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 195 MBytes 163 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 192 MBytes 160 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 195 MBytes 163 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 192 MBytes 161 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 973 MBytes 816 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 958 MBytes 802 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 499 MBytes 418 Mbits/sec 1208
sender
[ 5] 0.00-10.00 sec 487 MBytes 409 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 149 MBytes 125 Mbits/sec 262 sender
[ 7] 0.00-10.00 sec 146 MBytes 122 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 158 MBytes 132 Mbits/sec 199 sender
[ 9] 0.00-10.00 sec 154 MBytes 129 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 179 MBytes 149 Mbits/sec 209 sender
[ 11] 0.00-10.00 sec 175 MBytes 147 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 128 MBytes 107 Mbits/sec 386 sender
[ 13] 0.00-10.00 sec 125 MBytes 105 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.09 GBytes 931 Mbits/sec 2264
sender
[SUM] 0.00-10.00 sec 1.06 GBytes 912 Mbits/sec
receiver
3.8.4-NAPI w/ TSO & GSO (Without buffer overrun patch)
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 204 MBytes 171 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 201 MBytes 169 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 203 MBytes 170 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 201 MBytes 168 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 205 MBytes 172 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 202 MBytes 169 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 204 MBytes 171 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 201 MBytes 169 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 204 MBytes 171 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 200 MBytes 168 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 1019 MBytes 855 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 1006 MBytes 842 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 281 MBytes 235 Mbits/sec 128 sender
[ 5] 0.00-10.00 sec 277 MBytes 232 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 267 MBytes 223 Mbits/sec 154 sender
[ 7] 0.00-10.00 sec 263 MBytes 221 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 170 MBytes 142 Mbits/sec 154 sender
[ 9] 0.00-10.00 sec 166 MBytes 139 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 161 MBytes 135 Mbits/sec 211 sender
[ 11] 0.00-10.00 sec 158 MBytes 132 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 219 MBytes 183 Mbits/sec 116 sender
[ 13] 0.00-10.00 sec 216 MBytes 181 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.07 GBytes 919 Mbits/sec 763 sender
[SUM] 0.00-10.00 sec 1.05 GBytes 906 Mbits/sec
receiver
3.8.4-NAPI w/o TSO & GSO (Without buffer overrun patch)
iperf3 -c bouygues.iperf.fr -d -P 5
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 220 MBytes 184 Mbits/sec 0 sender
[ 5] 0.00-10.02 sec 218 MBytes 182 Mbits/sec
receiver
[ 7] 0.00-10.00 sec 220 MBytes 185 Mbits/sec 0 sender
[ 7] 0.00-10.02 sec 217 MBytes 182 Mbits/sec
receiver
[ 9] 0.00-10.00 sec 216 MBytes 182 Mbits/sec 0 sender
[ 9] 0.00-10.02 sec 213 MBytes 179 Mbits/sec
receiver
[ 11] 0.00-10.00 sec 220 MBytes 185 Mbits/sec 0 sender
[ 11] 0.00-10.02 sec 218 MBytes 182 Mbits/sec
receiver
[ 13] 0.00-10.00 sec 221 MBytes 185 Mbits/sec 0 sender
[ 13] 0.00-10.02 sec 218 MBytes 182 Mbits/sec
receiver
[SUM] 0.00-10.00 sec 1.07 GBytes 920 Mbits/sec 0 sender
[SUM] 0.00-10.02 sec 1.06 GBytes 907 Mbits/sec
receiver
iperf3 -c bouygues.iperf.fr -d -P 5 -R
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.02 sec 259 MBytes 217 Mbits/sec 67 sender
[ 5] 0.00-10.00 sec 255 MBytes 214 Mbits/sec
receiver
[ 7] 0.00-10.02 sec 256 MBytes 214 Mbits/sec 168 sender
[ 7] 0.00-10.00 sec 252 MBytes 212 Mbits/sec
receiver
[ 9] 0.00-10.02 sec 260 MBytes 217 Mbits/sec 189 sender
[ 9] 0.00-10.00 sec 256 MBytes 215 Mbits/sec
receiver
[ 11] 0.00-10.02 sec 165 MBytes 138 Mbits/sec 237 sender
[ 11] 0.00-10.00 sec 161 MBytes 135 Mbits/sec
receiver
[ 13] 0.00-10.02 sec 172 MBytes 144 Mbits/sec 220 sender
[ 13] 0.00-10.00 sec 169 MBytes 142 Mbits/sec
receiver
[SUM] 0.00-10.02 sec 1.08 GBytes 930 Mbits/sec 881 sender
[SUM] 0.00-10.00 sec 1.07 GBytes 917 Mbits/sec
receiver
^ permalink raw reply
* [Bug 14442] Shell command injection vulnerability in mount.cifs
From: samba-bugs @ 2020-07-17 3:50 UTC (permalink / raw)
To: cifs-qa
In-Reply-To: <bug-14442-10630@https.bugzilla.samba.org/>
https://bugzilla.samba.org/show_bug.cgi?id=14442
--- Comment #2 from Vadim Lebedev <vadim@mbdsys.com> ---
It's a step in the right direction,
but consider the case when systemd-ask-password is a shell script with(
#!/bin/sh)
I believe the vulnerability will be still present....
Maybe the best way will be to scan the option string for presence of "$(" and
prefix the '$' by '\' or abort the operation?
--
You are receiving this mail because:
You are the QA Contact for the bug.
^ permalink raw reply
* Re: [ANNOUNCE] Git for Windows 2.28.0-rc0
From: Kaartic Sivaraam @ 2020-07-17 3:49 UTC (permalink / raw)
To: Johannes Schindelin, git-for-windows, git, git-packagers
In-Reply-To: <20200710135935.6416-1-johannes.schindelin@gmx.de>
Hi Johannes,
On 10 ஜூலை, 2020 7:29:35 PM IST, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:
>Dear Git users,
>
>I hereby announce that Git for Windows 2.28.0-rc0 is available from:
>
>https://github.com/git-for-windows/git/releases/tag/v2.28.0-rc0.windows.1
>
Thanks. I just installed it in my local machine and it seems to work fine for me.
>Changes since Git for Windows v2.27.0 (June 1st 2020)
>
>New Features
>
> * Comes with Git v2.28.0-rc0.
> * Comes with subversion v1.14.0.
> * Comes with MSYS2 runtime (Git for Windows flavor) based on Cygwin
> 3.1.5.
> * Comes with the designated successor of Git Credential Manager for
> Windows (GCM for Windows), the cross-platform Git Credential
> Manager Core. For now, this is opt-in, with the idea of eventually
> retiring GCM for Windows.
> * Comes with cURL v7.71.1.
> * Comes with Perl v5.32.0.
> * Comes with MSYS2 runtime (Git for Windows flavor) based on Cygwin
> 3.1.6.
> * Comes with GNU Privacy Guard v2.2.21.
>
The above has "Comes with MSYS2 runtime (Git for Windows flavor) based on Cygwin ..." for both 3.1.5 and 3.1.6. I wonder if it really comes with two MSYS2 runtimes.
--
Sivaraam
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [PATCH 2/2] media: coda: Add more H264 levels for CODA960
From: Ezequiel Garcia @ 2020-07-17 3:49 UTC (permalink / raw)
To: linux-media
Cc: Hans Verkuil, Philipp Zabel, Robert Beckett, Nicolas Dufresne,
kernel, stable, Ezequiel Garcia
In-Reply-To: <20200717034923.219524-1-ezequiel@collabora.com>
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
This add H264 level 4.1, 4.2 and 5.0 to the list of supported formats.
While the hardware does not fully support these levels, it do support
most of them. The constraints on frame size and pixel formats already
cover the limitation.
This fixes negotiation of level on GStreamer 1.17.1.
Cc: stable@vger.kernel.org
Fixes: 42a68012e67c2 ("media: coda: add read-only h.264 decoder profile/level controls")
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
drivers/media/platform/coda/coda-common.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
index c641d1608825..d0fc573d6ed9 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -2355,7 +2355,10 @@ static void coda_encode_ctrls(struct coda_ctx *ctx)
(1 << V4L2_MPEG_VIDEO_H264_LEVEL_3_0) |
(1 << V4L2_MPEG_VIDEO_H264_LEVEL_3_1) |
(1 << V4L2_MPEG_VIDEO_H264_LEVEL_3_2) |
- (1 << V4L2_MPEG_VIDEO_H264_LEVEL_4_0)),
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_4_0) |
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_4_1) |
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_4_2) |
+ (1 << V4L2_MPEG_VIDEO_H264_LEVEL_5_0)),
V4L2_MPEG_VIDEO_H264_LEVEL_4_0);
}
v4l2_ctrl_new_std(&ctx->ctrls, &coda_ctrl_ops,
@@ -2428,7 +2431,7 @@ static void coda_decode_ctrls(struct coda_ctx *ctx)
ctx->dev->devtype->product == CODA_7541)
max = V4L2_MPEG_VIDEO_H264_LEVEL_4_0;
else if (ctx->dev->devtype->product == CODA_960)
- max = V4L2_MPEG_VIDEO_H264_LEVEL_4_1;
+ max = V4L2_MPEG_VIDEO_H264_LEVEL_5_0;
else
return;
ctx->h264_level_ctrl = v4l2_ctrl_new_std_menu(&ctx->ctrls,
--
2.27.0
^ permalink raw reply related
* [PATCH 1/2] media: coda: Fix reported H264 profile
From: Ezequiel Garcia @ 2020-07-17 3:49 UTC (permalink / raw)
To: linux-media
Cc: Hans Verkuil, Philipp Zabel, Robert Beckett, Nicolas Dufresne,
kernel, stable, Ezequiel Garcia
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
The CODA960 manual states that ASO/FMO features of baseline are not
supported, so for this reason this driver should only report
constrained baseline support.
This fixes negotiation issue with constrained baseline content
on GStreamer 1.17.1.
Cc: stable@vger.kernel.org
Fixes: 42a68012e67c2 ("media: coda: add read-only h.264 decoder profile/level controls")
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
drivers/media/platform/coda/coda-common.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
index 3ab3d976d8ca..c641d1608825 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -2335,8 +2335,8 @@ static void coda_encode_ctrls(struct coda_ctx *ctx)
V4L2_CID_MPEG_VIDEO_H264_CHROMA_QP_INDEX_OFFSET, -12, 12, 1, 0);
v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
V4L2_CID_MPEG_VIDEO_H264_PROFILE,
- V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE, 0x0,
- V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE);
+ V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE, 0x0,
+ V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE);
if (ctx->dev->devtype->product == CODA_HX4 ||
ctx->dev->devtype->product == CODA_7541) {
v4l2_ctrl_new_std_menu(&ctx->ctrls, &coda_ctrl_ops,
@@ -2417,7 +2417,7 @@ static void coda_decode_ctrls(struct coda_ctx *ctx)
ctx->h264_profile_ctrl = v4l2_ctrl_new_std_menu(&ctx->ctrls,
&coda_ctrl_ops, V4L2_CID_MPEG_VIDEO_H264_PROFILE,
V4L2_MPEG_VIDEO_H264_PROFILE_HIGH,
- ~((1 << V4L2_MPEG_VIDEO_H264_PROFILE_BASELINE) |
+ ~((1 << V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_BASELINE) |
(1 << V4L2_MPEG_VIDEO_H264_PROFILE_MAIN) |
(1 << V4L2_MPEG_VIDEO_H264_PROFILE_HIGH)),
V4L2_MPEG_VIDEO_H264_PROFILE_HIGH);
--
2.27.0
^ permalink raw reply related
* Re: [PATCH v5 15/22] fsnotify: send event with parent/name info to sb/mount/non-dir marks
From: Amir Goldstein @ 2020-07-17 3:49 UTC (permalink / raw)
To: Jan Kara; +Cc: linux-fsdevel
In-Reply-To: <20200716223441.GA5085@quack2.suse.cz>
> OK, nice trick but for this series, I'd like to keep the original ignore
> mask behavior (bug to bug compatibility) or possibly let parent's ignore
> mask be applied only for events being sent to the parent due to its
> FS_EVENT_ON_CHILD.
That should be easy if we set the FS_EVENT_ON_CHILD flag only for
the case of a watching parent.
And I believe that would make the flag meaningful again and not
redundant as you now see it.
Please note that the series is already not "bug compatible", because
the patch " send event to parent and child with single callback"
already fixes the combination parent watch + child ignore, which
did not work before and this is declared in commit message.
> Can you please fix that up?
Will do.
I will also take care of LTP test coverage for the ignore mask cases
that have been fixed and for dnotify/inotify parent+child watching case.
> I won't get to it before I
> leave for vacation but once I return, I'd like to just pick the fixed up
> commit and push everything to linux-next... Thanks!
>
Thanks a lot for everything!
Amir.
^ permalink raw reply
* RE: [PATCH 0/2] Modularization of DFL private feature drivers
From: Wu, Hao @ 2020-07-17 3:48 UTC (permalink / raw)
To: Tom Rix, Xu, Yilun, mdf@kernel.org, linux-fpga@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: lgoncalv@redhat.com, Matthew Gerlach
In-Reply-To: <0c7c63b8-5444-2deb-9fed-18956a5ad938@redhat.com>
> Subject: Re: [PATCH 0/2] Modularization of DFL private feature drivers
>
> Generally i think this is a good approach.
>
> However I do have concern.
>
> The feature_id in dfl is magic number, similar to pci id but without a vendor
> id.
>
> Is it possible to add something like a vendor id so different vendors would
> not have to be so careful to use a unique id ?
Hi Tom,
Thanks for the comments.
Here is only one field defined in spec, that is feature id to distinguish one
feature with another one. There is no vendor id here I think, and several
cards are using this for now and seems not possible to change DFH format
for these products. : (
I fully understand the concern is the feature id management, and potential
conflicts there from different vendors. One possible method to resolve this
is managing the ids in a public place (web? Or just the driver header file for
feature id definition), all vendors can request some feature ids, and other
people can see which feature ids have been used so that they can avoid
using conflict ones with other people.
And in the later version DFH, this feature id will be replaced with GUID
I think, so it can resolve the conflict problems from different vendors?
But now, we still need to handle the existing ones. : )
Thanks
Hao
>
> This touches some of the matching function of the bus ops. Could there be a
> way for bus ops to be used so that there could be multiple matching
> function. Maybe the one in 0002 as a default so users could override it ?
>
> The use case I am worrying about is an OEM. The OEM uses an unclaimed
> feature_id and supplies their own platform device device driver to match the
> feature_id. But some later version of the kernel claims this feature_id and
> the OEM's driver no longer works and since the value comes from pci config
> space it is difficult to change.
>
> So looking for something like
>
> register_feature_matcher((*bus_match)(struct device *dev, struct
> device_driver *drv))
>
> static int dfl_bus_match_default(struct device *dev, struct device_driver *drv)
> {
> struct dfl_device *dfl_dev = to_dfl_dev(dev);
> struct dfl_driver *dfl_drv = to_dfl_drv(drv);
> const struct dfl_device_id *id_entry = dfl_drv->id_table;
>
> while (id_entry->feature_id) {
> if (dfl_match_one_device(id_entry, dfl_dev)) {
> dfl_dev->id_entry = id_entry;
> return 1;
> }
> id_entry++;
> }
>
> return 0;
> }
>
> register_feature_matcher(&dfl_bus_match_default)
>
> static int dfl_bus_match(struct device *dev, struct device_driver *drv)
> {
>
> struct dfl_device *dfl_dev = to_dfl_dev(dev);
> struct dfl_driver *dfl_drv = to_dfl_drv(drv);
> const struct dfl_device_id *id_entry = dfl_drv->id_table;
>
> while (id_entry->feature_id) {
>
> matcher = Loop over matchers()
>
> if (matcher(dev, drv)) {
> dfl_dev->id_entry = id_entry;
> return 1;
> }
> id_entry++;
> }
>
> return 0;
> }
>
> Or maybe use some of the unused bits in the dfl header to add a second
> vendor-like id and change existing matcher to look feature_id and
> vendor_like_id.
>
> Tom
>
>
>
> On 7/14/20 10:38 PM, Xu Yilun wrote:
> > This patchset makes it possible to develop independent driver modules
> > for DFL private features. It also helps to leverage existing kernel
> > drivers to enable some IP blocks in DFL.
> >
> > Xu Yilun (2):
> > fpga: dfl: map feature mmio resources in their own feature drivers
> > fpga: dfl: create a dfl bus type to support DFL devices
> >
> > Documentation/ABI/testing/sysfs-bus-dfl | 15 ++
> > drivers/fpga/dfl-pci.c | 21 +-
> > drivers/fpga/dfl.c | 435 +++++++++++++++++++++++++++-----
> > drivers/fpga/dfl.h | 91 ++++++-
> > 4 files changed, 492 insertions(+), 70 deletions(-)
> > create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl
> >
^ permalink raw reply
* [renesas-devel:renesas-arm-dt-for-v5.9] BUILD SUCCESS bb899a12d97cf468585388445de44f0beea8048f
From: kernel test robot @ 2020-07-17 3:43 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-renesas-soc
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git renesas-arm-dt-for-v5.9
branch HEAD: bb899a12d97cf468585388445de44f0beea8048f arm64: dts: renesas: r8a774e1: Add CAN[FD] support
elapsed time: 722m
configs tested: 79
configs skipped: 90
The following configs have been built successfully.
More configs may be tested in the coming days.
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
i386 allnoconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a012-20200716
x86_64 randconfig-a011-20200716
x86_64 randconfig-a016-20200716
x86_64 randconfig-a014-20200716
x86_64 randconfig-a013-20200716
x86_64 randconfig-a015-20200716
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [renesas-devel:next] BUILD SUCCESS 8e5a980249d601b3371e44da166382904385fc6a
From: kernel test robot @ 2020-07-17 3:42 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-renesas-soc
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git next
branch HEAD: 8e5a980249d601b3371e44da166382904385fc6a Merge branch 'renesas-arm-dt-for-v5.9' into renesas-next
elapsed time: 722m
configs tested: 92
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200716
i386 randconfig-a005-20200716
i386 randconfig-a002-20200716
i386 randconfig-a006-20200716
i386 randconfig-a003-20200716
i386 randconfig-a004-20200716
x86_64 randconfig-a012-20200716
x86_64 randconfig-a011-20200716
x86_64 randconfig-a016-20200716
x86_64 randconfig-a014-20200716
x86_64 randconfig-a013-20200716
x86_64 randconfig-a015-20200716
i386 randconfig-a016-20200716
i386 randconfig-a011-20200716
i386 randconfig-a015-20200716
i386 randconfig-a012-20200716
i386 randconfig-a013-20200716
i386 randconfig-a014-20200716
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
x86_64 rhel
x86_64 lkp
x86_64 fedora-25
x86_64 rhel-7.6-kselftests
x86_64 rhel-8.3
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH v4] media: videobuf2: Print videobuf2 buffer state by name
From: Ezequiel Garcia @ 2020-07-17 3:39 UTC (permalink / raw)
To: linux-media; +Cc: Hans Verkuil, Ezequiel Garcia, kernel, Nicolas Dufresne
In-Reply-To: <20200710130010.160712-1-ezequiel@collabora.com>
For debugging purposes, seeing the state integer
representation is really inconvenient.
Improve this and be developer-friendly by printing
the state name instead.
Suggested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
---
v4:
* Drop inline modifier.
* Add back static modifier from the now local name array.
v3:
* Drop static modifier from the now local name array.
v2:
* Use a proper function instead of a C macro.
.../media/common/videobuf2/videobuf2-core.c | 35 ++++++++++++++-----
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c
index abaf28e057eb..f544d3393e9d 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -191,6 +191,23 @@ module_param(debug, int, 0644);
static void __vb2_queue_cancel(struct vb2_queue *q);
static void __enqueue_in_driver(struct vb2_buffer *vb);
+static const char *vb2_state_name(enum vb2_buffer_state s)
+{
+ static const char * const state_names[] = {
+ [VB2_BUF_STATE_DEQUEUED] = "dequeued",
+ [VB2_BUF_STATE_IN_REQUEST] = "in request",
+ [VB2_BUF_STATE_PREPARING] = "preparing",
+ [VB2_BUF_STATE_QUEUED] = "queued",
+ [VB2_BUF_STATE_ACTIVE] = "active",
+ [VB2_BUF_STATE_DONE] = "done",
+ [VB2_BUF_STATE_ERROR] = "error",
+ };
+
+ if ((unsigned int)(s) < ARRAY_SIZE(state_names))
+ return state_names[s];
+ return "unknown";
+}
+
/*
* __vb2_buf_mem_alloc() - allocate video memory for the given buffer
*/
@@ -1015,8 +1032,8 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state)
*/
vb->cnt_buf_done++;
#endif
- dprintk(q, 4, "done processing on buffer %d, state: %d\n",
- vb->index, state);
+ dprintk(q, 4, "done processing on buffer %d, state: %s\n",
+ vb->index, vb2_state_name(state));
if (state != VB2_BUF_STATE_QUEUED)
__vb2_buf_mem_finish(vb);
@@ -1490,8 +1507,8 @@ int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
vb = q->bufs[index];
if (vb->state != VB2_BUF_STATE_DEQUEUED) {
- dprintk(q, 1, "invalid buffer state %d\n",
- vb->state);
+ dprintk(q, 1, "invalid buffer state %s\n",
+ vb2_state_name(vb->state));
return -EINVAL;
}
if (vb->prepared) {
@@ -1670,7 +1687,8 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
dprintk(q, 1, "buffer still being prepared\n");
return -EINVAL;
default:
- dprintk(q, 1, "invalid buffer state %d\n", vb->state);
+ dprintk(q, 1, "invalid buffer state %s\n",
+ vb2_state_name(vb->state));
return -EINVAL;
}
@@ -1884,7 +1902,8 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int *pindex, void *pb,
dprintk(q, 3, "returning done buffer with errors\n");
break;
default:
- dprintk(q, 1, "invalid buffer state\n");
+ dprintk(q, 1, "invalid buffer state %s\n",
+ vb2_state_name(vb->state));
return -EINVAL;
}
@@ -1915,8 +1934,8 @@ int vb2_core_dqbuf(struct vb2_queue *q, unsigned int *pindex, void *pb,
media_request_put(vb->request);
vb->request = NULL;
- dprintk(q, 2, "dqbuf of buffer %d, with state %d\n",
- vb->index, vb->state);
+ dprintk(q, 2, "dqbuf of buffer %d, state: %s\n",
+ vb->index, vb2_state_name(vb->state));
return 0;
--
2.27.0
^ permalink raw reply related
* [git pull] drm fixes for 5.8-rc6
From: Dave Airlie @ 2020-07-17 3:42 UTC (permalink / raw)
To: Linus Torvalds, Daniel Vetter; +Cc: dri-devel, LKML
Hi Linus,
Weekly fixes pull, big bigger than I'd normally like, but they are
fairly scattered and small individually. The vmwgfx one is a black
screen regression, otherwise the largest is an MST encoder fix for
amdgpu which results in a WARN in some cases, and a scattering of i915
fixes.
I'm tracking two regressions at the moment that hopefully we get
nailed down this week for rc7.
Dave.
drm-fixes-2020-07-17-1:
drm fixes for 5.8-rc6
dma-buf:
- sleeping atomic fix
amdgpu:
- Fix a race condition with KIQ
- Preemption fix
- Fix handling of fake MST encoders
- OLED panel fix
- Handle allocation failure in stream construction
- Renoir SMC fix
- SDMA 5.x fix
i915:
- FBC w/a stride fix
- Fix use-after-free fix on module reload
- Ignore irq enabling on the virtual engines to fix device sleep
- Use GTT when saving/restoring engine GPR
- Fix selftest sort function
vmwgfx:
- black screen fix
aspeed:
- fbcon init warn fix
The following changes since commit 11ba468877bb23f28956a35e896356252d63c983:
Linux 5.8-rc5 (2020-07-12 16:34:50 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-17-1
for you to fetch changes up to adbe8a3cae94a63e9f416795c750237a9b789124:
Merge tag 'amd-drm-fixes-5.8-2020-07-15' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-17
13:29:00 +1000)
----------------------------------------------------------------
drm fixes for 5.8-rc6
dma-buf:
- sleeping atomic fix
amdgpu:
- Fix a race condition with KIQ
- Preemption fix
- Fix handling of fake MST encoders
- OLED panel fix
- Handle allocation failure in stream construction
- Renoir SMC fix
- SDMA 5.x fix
i915:
- FBC w/a stride fix
- Fix use-after-free fix on module reload
- Ignore irq enabling on the virtual engines to fix device sleep
- Use GTT when saving/restoring engine GPR
- Fix selftest sort function
vmwgfx:
- black screen fix
aspeed:
- fbcon init warn fix
----------------------------------------------------------------
Alex Deucher (1):
drm/amdgpu/display: create fake mst encoders ahead of time (v4)
Charan Teja Kalla (1):
dmabuf: use spinlock to access dmabuf->name
Chris Wilson (2):
drm/i915/gt: Ignore irq enabling on the virtual engines
drm/i915/gt: Only swap to a random sibling once upon creation
Dave Airlie (4):
Merge branch 'vmwgfx-fixes-5.8' of
git://people.freedesktop.org/~sroland/linux into drm-fixes
Merge tag 'drm-misc-fixes-2020-07-15' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Merge tag 'drm-intel-fixes-2020-07-15' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Merge tag 'amd-drm-fixes-5.8-2020-07-15' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
Guenter Roeck (1):
drm/aspeed: Call drm_fbdev_generic_setup after drm_dev_register
Jack Xiao (2):
drm/amdgpu/gfx10: fix race condition for kiq
drm/amdgpu: fix preemption unit test
Josip Pavic (1):
drm/amd/display: handle failed allocation during stream construction
Maarten Lankhorst (1):
drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.
Roland Scheidegger (1):
drm/vmwgfx: fix update of display surface when resolution changes
Sudeep Holla (1):
drm/i915/selftests: Fix compare functions provided for sorting
Umesh Nerlige Ramappa (1):
drm/i915/perf: Use GTT when saving/restoring engine GPR
Ville Syrjälä (1):
drm/i915: Recalculate FBC w/a stride when needed
Xiaojie Yuan (1):
drm/amdgpu/sdma5: fix wptr overwritten in ->get_wptr()
chen gong (1):
drm/amdgpu/powerplay: Modify SMC message name for setting power
profile mode
hersen wu (1):
drm/amd/display: OLED panel backlight adjust not work with
external display connected
drivers/dma-buf/dma-buf.c | 11 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++++++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 9 +++-
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 26 ++++-------
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 ++++++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 11 ++++-
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 53 +++++++++++-----------
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h | 3 ++
drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 19 ++++++--
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 2 +-
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +-
drivers/gpu/drm/i915/display/intel_fbc.c | 33 +++++++++++---
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +---
drivers/gpu/drm/i915/gt/intel_lrc.c | 19 ++------
drivers/gpu/drm/i915/gt/selftest_rps.c | 8 ++--
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 ++--
include/linux/dma-buf.h | 1 +
19 files changed, 153 insertions(+), 99 deletions(-)
^ permalink raw reply
* [git pull] drm fixes for 5.8-rc6
From: Dave Airlie @ 2020-07-17 3:42 UTC (permalink / raw)
To: Linus Torvalds, Daniel Vetter; +Cc: LKML, dri-devel
Hi Linus,
Weekly fixes pull, big bigger than I'd normally like, but they are
fairly scattered and small individually. The vmwgfx one is a black
screen regression, otherwise the largest is an MST encoder fix for
amdgpu which results in a WARN in some cases, and a scattering of i915
fixes.
I'm tracking two regressions at the moment that hopefully we get
nailed down this week for rc7.
Dave.
drm-fixes-2020-07-17-1:
drm fixes for 5.8-rc6
dma-buf:
- sleeping atomic fix
amdgpu:
- Fix a race condition with KIQ
- Preemption fix
- Fix handling of fake MST encoders
- OLED panel fix
- Handle allocation failure in stream construction
- Renoir SMC fix
- SDMA 5.x fix
i915:
- FBC w/a stride fix
- Fix use-after-free fix on module reload
- Ignore irq enabling on the virtual engines to fix device sleep
- Use GTT when saving/restoring engine GPR
- Fix selftest sort function
vmwgfx:
- black screen fix
aspeed:
- fbcon init warn fix
The following changes since commit 11ba468877bb23f28956a35e896356252d63c983:
Linux 5.8-rc5 (2020-07-12 16:34:50 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-17-1
for you to fetch changes up to adbe8a3cae94a63e9f416795c750237a9b789124:
Merge tag 'amd-drm-fixes-5.8-2020-07-15' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-17
13:29:00 +1000)
----------------------------------------------------------------
drm fixes for 5.8-rc6
dma-buf:
- sleeping atomic fix
amdgpu:
- Fix a race condition with KIQ
- Preemption fix
- Fix handling of fake MST encoders
- OLED panel fix
- Handle allocation failure in stream construction
- Renoir SMC fix
- SDMA 5.x fix
i915:
- FBC w/a stride fix
- Fix use-after-free fix on module reload
- Ignore irq enabling on the virtual engines to fix device sleep
- Use GTT when saving/restoring engine GPR
- Fix selftest sort function
vmwgfx:
- black screen fix
aspeed:
- fbcon init warn fix
----------------------------------------------------------------
Alex Deucher (1):
drm/amdgpu/display: create fake mst encoders ahead of time (v4)
Charan Teja Kalla (1):
dmabuf: use spinlock to access dmabuf->name
Chris Wilson (2):
drm/i915/gt: Ignore irq enabling on the virtual engines
drm/i915/gt: Only swap to a random sibling once upon creation
Dave Airlie (4):
Merge branch 'vmwgfx-fixes-5.8' of
git://people.freedesktop.org/~sroland/linux into drm-fixes
Merge tag 'drm-misc-fixes-2020-07-15' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Merge tag 'drm-intel-fixes-2020-07-15' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Merge tag 'amd-drm-fixes-5.8-2020-07-15' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
Guenter Roeck (1):
drm/aspeed: Call drm_fbdev_generic_setup after drm_dev_register
Jack Xiao (2):
drm/amdgpu/gfx10: fix race condition for kiq
drm/amdgpu: fix preemption unit test
Josip Pavic (1):
drm/amd/display: handle failed allocation during stream construction
Maarten Lankhorst (1):
drm/i915: Move cec_notifier to intel_hdmi_connector_unregister, v2.
Roland Scheidegger (1):
drm/vmwgfx: fix update of display surface when resolution changes
Sudeep Holla (1):
drm/i915/selftests: Fix compare functions provided for sorting
Umesh Nerlige Ramappa (1):
drm/i915/perf: Use GTT when saving/restoring engine GPR
Ville Syrjälä (1):
drm/i915: Recalculate FBC w/a stride when needed
Xiaojie Yuan (1):
drm/amdgpu/sdma5: fix wptr overwritten in ->get_wptr()
chen gong (1):
drm/amdgpu/powerplay: Modify SMC message name for setting power
profile mode
hersen wu (1):
drm/amd/display: OLED panel backlight adjust not work with
external display connected
drivers/dma-buf/dma-buf.c | 11 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++++++--
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 9 +++-
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 26 ++++-------
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 ++++++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 11 ++++-
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 53 +++++++++++-----------
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h | 3 ++
drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 19 ++++++--
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 2 +-
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +-
drivers/gpu/drm/i915/display/intel_fbc.c | 33 +++++++++++---
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +---
drivers/gpu/drm/i915/gt/intel_lrc.c | 19 ++------
drivers/gpu/drm/i915/gt/selftest_rps.c | 8 ++--
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_perf.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 ++--
include/linux/dma-buf.h | 1 +
19 files changed, 153 insertions(+), 99 deletions(-)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/2] libsubcmd: Fix OPT_CALLBACK_SET()
From: Ravi Bangoria @ 2020-07-17 3:40 UTC (permalink / raw)
To: acme; +Cc: jolsa, linux-kernel, Ravi Bangoria
In-Reply-To: <20200619133412.50705-1-ravi.bangoria@linux.ibm.com>
Hi Arnaldo,
Can you please consider this trivial fix.
Ravi
On 6/19/20 7:04 PM, Ravi Bangoria wrote:
> Any option macro with _SET suffix should set opt->set variable which
> is not happening for OPT_CALLBACK_SET(). This is causing issues with
> perf record --switch-output-event. Fix that.
>
> Before:
> # ./perf record --overwrite -e sched:*switch,syscalls:sys_enter_mmap \
> --switch-output-event syscalls:sys_enter_mmap
> ^C[ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.297 MB perf.data (657 samples) ]
>
> After:
>
> $ ./perf record --overwrite -e sched:*switch,syscalls:sys_enter_mmap \
> --switch-output-event syscalls:sys_enter_mmap
> [ perf record: dump data: Woken up 1 times ]
> [ perf record: Dump perf.data.2020061918144542 ]
> [ perf record: dump data: Woken up 1 times ]
> [ perf record: Dump perf.data.2020061918144608 ]
> [ perf record: dump data: Woken up 1 times ]
> [ perf record: Dump perf.data.2020061918144660 ]
> ^C[ perf record: dump data: Woken up 1 times ]
> [ perf record: Dump perf.data.2020061918144784 ]
> [ perf record: Woken up 0 times to write data ]
> [ perf record: Dump perf.data.2020061918144803 ]
> [ perf record: Captured and wrote 0.419 MB perf.data.<timestamp> ]
>
> Fixes: 636eb4d001b1 ("libsubcmd: Introduce OPT_CALLBACK_SET()")
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> ---
> tools/lib/subcmd/parse-options.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/lib/subcmd/parse-options.c b/tools/lib/subcmd/parse-options.c
> index dbb9efbf718a..39ebf6192016 100644
> --- a/tools/lib/subcmd/parse-options.c
> +++ b/tools/lib/subcmd/parse-options.c
> @@ -237,6 +237,9 @@ static int get_value(struct parse_opt_ctx_t *p,
> return err;
>
> case OPTION_CALLBACK:
> + if (opt->set)
> + *(bool *)opt->set = true;
> +
> if (unset)
> return (*opt->callback)(opt, NULL, 1) ? (-1) : 0;
> if (opt->flags & PARSE_OPT_NOARG)
>
^ permalink raw reply
* cron job: media_tree daily build: ERRORS
From: Hans Verkuil @ 2020-07-17 3:41 UTC (permalink / raw)
To: linux-media
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Fri Jul 17 05:00:10 CEST 2020
media-tree git hash: 6f01dfb760c027d5dd6199d91ee9599f2676b5c6
media_build git hash: 3b826169bba299e5a7352f79759f3c67a4c9fb7a
v4l-utils git hash: e50041186be9f69dd94b64fb924115201726e72a
edid-decode git hash: f20c85d7b4c537e0d458f85c4da9f45cd3c0fbd2
gcc version: i686-linux-gcc (GCC) 9.3.0
sparse repo: https://git.linuxtv.org/mchehab/sparse.git
sparse version: 0.6.1
smatch repo: https://git.linuxtv.org/mchehab/smatch.git
smatch version: v0.5.0-6381-g344ef612
build-scripts repo: https://git.linuxtv.org/hverkuil/build-scripts.git
build-scripts git hash: 5540ce1b67f5015886e850a4775d2eace9efe922
host hardware: x86_64
host os: 5.6.0-1-amd64
linux-git-sh: OK
linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-stm32: OK
linux-git-arm-pxa: OK
linux-git-mips: OK
linux-git-arm64: OK
linux-git-powerpc64: OK
linux-git-arm-multi: OK
linux-git-i686: OK
linux-git-x86_64: OK
Check COMPILE_TEST: WARNINGS: VIDEO_TEGRA
Check for strcpy/strncpy/strlcpy: WARNINGS: found 3 strcpy(), 3 strncpy(), 3 strlcpy()
linux-3.10.108-i686: OK
linux-3.10.108-x86_64: OK
linux-3.11.10-i686: OK
linux-3.11.10-x86_64: OK
linux-3.12.74-i686: OK
linux-3.12.74-x86_64: OK
linux-3.13.11-i686: OK
linux-3.13.11-x86_64: OK
linux-3.14.79-i686: OK
linux-3.14.79-x86_64: OK
linux-3.15.10-i686: OK
linux-3.15.10-x86_64: OK
linux-3.16.81-i686: OK
linux-3.16.81-x86_64: OK
linux-3.17.8-i686: OK
linux-3.17.8-x86_64: OK
linux-3.18.136-i686: OK
linux-3.18.136-x86_64: OK
linux-3.19.8-i686: OK
linux-3.19.8-x86_64: OK
linux-4.0.9-i686: OK
linux-4.0.9-x86_64: OK
linux-4.1.52-i686: OK
linux-4.1.52-x86_64: OK
linux-4.2.8-i686: OK
linux-4.2.8-x86_64: OK
linux-4.3.6-i686: OK
linux-4.3.6-x86_64: OK
linux-4.4.212-i686: OK
linux-4.4.212-x86_64: OK
linux-4.5.7-i686: OK
linux-4.5.7-x86_64: OK
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: OK
linux-4.7.10-i686: OK
linux-4.7.10-x86_64: OK
linux-4.8.17-i686: OK
linux-4.8.17-x86_64: OK
linux-4.9.212-i686: OK
linux-4.9.212-x86_64: OK
linux-4.10.17-i686: OK
linux-4.10.17-x86_64: OK
linux-4.11.12-i686: OK
linux-4.11.12-x86_64: OK
linux-4.12.14-i686: OK
linux-4.12.14-x86_64: OK
linux-4.13.16-i686: OK
linux-4.13.16-x86_64: OK
linux-4.14.169-i686: OK
linux-4.14.169-x86_64: OK
linux-4.15.18-i686: OK
linux-4.15.18-x86_64: OK
linux-4.16.18-i686: OK
linux-4.16.18-x86_64: OK
linux-4.17.19-i686: OK
linux-4.17.19-x86_64: OK
linux-4.18.20-i686: OK
linux-4.18.20-x86_64: OK
linux-4.19.101-i686: OK
linux-4.19.101-x86_64: OK
linux-4.20.15-i686: OK
linux-4.20.15-x86_64: OK
linux-5.0.15-i686: OK
linux-5.0.15-x86_64: OK
linux-5.1.1-i686: OK
linux-5.1.1-x86_64: OK
linux-5.2.1-i686: OK
linux-5.2.1-x86_64: OK
linux-5.3.1-i686: OK
linux-5.3.1-x86_64: OK
linux-5.4.17-i686: OK
linux-5.4.17-x86_64: OK
linux-5.5.1-i686: OK
linux-5.5.1-x86_64: OK
linux-5.6.1-i686: OK
linux-5.6.1-x86_64: OK
linux-5.7.2-i686: OK
linux-5.7.2-x86_64: OK
linux-5.8-rc1-i686: OK
linux-5.8-rc1-x86_64: OK
apps: OK
spec-git: OK
virtme: WARNINGS: Final Summary: 2943, Succeeded: 2943, Failed: 0, Warnings: 1
virtme-32: WARNINGS: Final Summary: 2779, Succeeded: 2779, Failed: 0, Warnings: 4
sparse: OK
smatch: ERRORS
Detailed results are available here:
http://www.xs4all.nl/~hverkuil/logs/Friday.log
Detailed regression test results are available here:
http://www.xs4all.nl/~hverkuil/logs/Friday-test-media.log
http://www.xs4all.nl/~hverkuil/logs/Friday-test-media-32.log
http://www.xs4all.nl/~hverkuil/logs/Friday-test-media-dmesg.log
Full logs are available here:
http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2
The Media Infrastructure API from this daily build is here:
http://www.xs4all.nl/~hverkuil/spec/index.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.