Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

Stewart Smith writes: > Madhavan Srinivasan writes: >>> * in patch 9 should opal_imc_counters_init return something other >>>than OPAL_SUCCESS in the case on invalid arguments? Maybe >>>OPAL_PARAMETER? (I think you fix

Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

Stewart Smith writes: > Madhavan Srinivasan writes: >>> * in patch 9 should opal_imc_counters_init return something other >>>than OPAL_SUCCESS in the case on invalid arguments? Maybe >>>OPAL_PARAMETER? (I think you fix this in a later patch anyway?) >> >> So, init call will

[PATCH v2 3/3] sched/deadline: Add statistics to track runtime underruns

Add accounting to track cases that runtime isn't running out, and export the information in "/proc//sched". Specifically, the patch adds three members "nr_underrun_sched", "nr_underrun_block", and "nr_underrun_yield" in sched_dl_entity: -@nr_underrun_sched hints some scheduling issue.

[PATCH v2 2/3] sched/deadline: Throttle the task when missing its deadline

dl_runtime_exceeded() only checks negative runtime, actually when the current deadline past, we should start a new period and zero out the remaining runtime as well. This patch improves dl_runtime_exceeded() to achieve that. Fixes: 269ad8015a6b ("sched/deadline: Avoid double-accounting in case

[PATCH v2 3/3] sched/deadline: Add statistics to track runtime underruns

Add accounting to track cases that runtime isn't running out, and export the information in "/proc//sched". Specifically, the patch adds three members "nr_underrun_sched", "nr_underrun_block", and "nr_underrun_yield" in sched_dl_entity: -@nr_underrun_sched hints some scheduling issue.

[PATCH v2 2/3] sched/deadline: Throttle the task when missing its deadline

dl_runtime_exceeded() only checks negative runtime, actually when the current deadline past, we should start a new period and zero out the remaining runtime as well. This patch improves dl_runtime_exceeded() to achieve that. Fixes: 269ad8015a6b ("sched/deadline: Avoid double-accounting in case

[PATCH v2 1/3] sched/deadline: Zero out positive runtime after throttling constrained tasks

When a contrained task is throttled by dl_check_constrained_dl(), it may carry the remaining positive runtime, as a result when dl_task_timer() fires and calls replenish_dl_entity(), it will not be replenished correctly due to the positive dl_se->runtime. This patch assigns its runtime to 0 if

[PATCH v2 1/3] sched/deadline: Zero out positive runtime after throttling constrained tasks

When a contrained task is throttled by dl_check_constrained_dl(), it may carry the remaining positive runtime, as a result when dl_task_timer() fires and calls replenish_dl_entity(), it will not be replenished correctly due to the positive dl_se->runtime. This patch assigns its runtime to 0 if

Re: [PATCH 0/2] net: Set maximum receive packet size on veth interfaces

On Tue, May 9, 2017 at 5:42 PM, Fredrik Markström wrote: > > Maybe I was unclear, the veth implementation drops all packers larger then the > configured MTU (on the receiving interface). > Most ethernet drivers accepts packets up to the ethernet MTU no matter the >

Re: [PATCH 0/2] net: Set maximum receive packet size on veth interfaces

On Tue, May 9, 2017 at 5:42 PM, Fredrik Markström wrote: > > Maybe I was unclear, the veth implementation drops all packers larger then the > configured MTU (on the receiving interface). > Most ethernet drivers accepts packets up to the ethernet MTU no matter the > configured MTU. As far as I can

[PATCH v3 2/3] arm64: dts: mt8173: Fix mdp device tree

From: Daniel Kurtz If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC

[PATCH v3 2/3] arm64: dts: mt8173: Fix mdp device tree

From: Daniel Kurtz If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also

[PATCH v3 0/3] Fix mdp device tree

Changes in v3: - Upload patches again because forget to add v2 in title Changes in v2: - Update commit message If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up

[PATCH v3 0/3] Fix mdp device tree

Changes in v3: - Upload patches again because forget to add v2 in title Changes in v2: - Update commit message If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up

[PATCH v3 3/3] media: mtk-mdp: Fix mdp device tree

From: Daniel Kurtz If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC

[PATCH v3 1/3] dt-bindings: mt8173: Fix mdp device tree

If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also simplifies the device tree.

[PATCH v3 3/3] media: mtk-mdp: Fix mdp device tree

From: Daniel Kurtz If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also

[PATCH v3 1/3] dt-bindings: mt8173: Fix mdp device tree

If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also simplifies the device tree.

Re: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

On Fri, 12 May 2017 02:50:32 + "Cheng, Collins" wrote: > Hi Helgaas, > > Some AMD GPUs have hardware support for graphics SR-IOV. > If the SR-IOV capable GPU is plugged into the SR-IOV incapable > platform. It would cause a problem on PCI resource allocation in >

Re: [PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

On Fri, 12 May 2017 02:50:32 + "Cheng, Collins" wrote: > Hi Helgaas, > > Some AMD GPUs have hardware support for graphics SR-IOV. > If the SR-IOV capable GPU is plugged into the SR-IOV incapable > platform. It would cause a problem on PCI resource allocation in > current Linux kernel. > >

Re: [PATCH 1/3] f2fs: split wio_mutex

On 2017/5/12 2:37, Jaegeuk Kim wrote: > On 05/09, Chao Yu wrote: >> From: Chao Yu >> >> Split wio_mutex to adjust different temperature bio cache. > > This can be rephrased like: Yup, let me resend this patch. Thanks, > > Signed-off-by: Chao Yu >

Re: [PATCH 1/3] f2fs: split wio_mutex

On 2017/5/12 2:37, Jaegeuk Kim wrote: > On 05/09, Chao Yu wrote: >> From: Chao Yu >> >> Split wio_mutex to adjust different temperature bio cache. > > This can be rephrased like: Yup, let me resend this patch. Thanks, > > Signed-off-by: Chao Yu > Signed-off-by: Jaegeuk Kim > --- >

Re: [PATCH] f2fs: split bio cache

On 2017/5/11 10:35, Jaegeuk Kim wrote: > On 05/11, Chao Yu wrote: >> On 2017/5/11 7:50, Jaegeuk Kim wrote: >>> On 05/09, Chao Yu wrote: Hi Jaegeuk, On 2017/5/9 5:23, Jaegeuk Kim wrote: > Hi Chao, > > I can't see a strong reason to split meta from data/node and rename the

Re: [PATCH] f2fs: split bio cache

On 2017/5/11 10:35, Jaegeuk Kim wrote: > On 05/11, Chao Yu wrote: >> On 2017/5/11 7:50, Jaegeuk Kim wrote: >>> On 05/09, Chao Yu wrote: Hi Jaegeuk, On 2017/5/9 5:23, Jaegeuk Kim wrote: > Hi Chao, > > I can't see a strong reason to split meta from data/node and rename the

[PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree

If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also simplifies the device tree.

[PATCH v2 0/3] Fix mdp device tree

If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also simplifies the device tree.

[PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree

If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also simplifies the device tree.

[PATCH v2 0/3] Fix mdp device tree

If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also simplifies the device tree.

[PATCH 2/3] arm64: dts: mt8173: Fix mdp device tree

From: Daniel Kurtz If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC

[PATCH 3/3] media: mtk-mdp: Fix mdp device tree

From: Daniel Kurtz If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC

[PATCH 2/3] arm64: dts: mt8173: Fix mdp device tree

From: Daniel Kurtz If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also

[PATCH 3/3] media: mtk-mdp: Fix mdp device tree

From: Daniel Kurtz If the mdp_* nodes are under an mdp sub-node, their corresponding platform device does not automatically get its iommu assigned properly. Fix this by moving the mdp component nodes up a level such that they are siblings of mdp and all other SoC subsystems. This also

Re: [PATCH v2] scsi: sg: don't return bogus Sg_requests

Johannes, > If the list search in sg_get_rq_mark() fails to find a valid request, > we return a bogus element. This then can later lead to a GPF in > sg_remove_scat(). > > So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case > the list search doesn't find a valid request.

Re: [PATCH v2] scsi: sg: don't return bogus Sg_requests

Johannes, > If the list search in sg_get_rq_mark() fails to find a valid request, > we return a bogus element. This then can later lead to a GPF in > sg_remove_scat(). > > So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case > the list search doesn't find a valid request.

Re: linux-next: Tree for May 12

Hi all, On Fri, 12 May 2017 13:12:16 +1000 Stephen Rothwell wrote: > > Below is a summary of the state of the merge. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (09d79d103371 Merge tag 'docs-4.12-2' of

Re: linux-next: Tree for May 12

Hi all, On Fri, 12 May 2017 13:12:16 +1000 Stephen Rothwell wrote: > > Below is a summary of the state of the merge. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (09d79d103371 Merge tag 'docs-4.12-2' of git://git.lwn.net/linux) Merging

linux-next: Tree for May 12

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170511: Non-merge commits (relative to Linus' tree): 520 583 files changed, 13977 insertions(+), 14719 deletions

linux-next: Tree for May 12

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170511: Non-merge commits (relative to Linus' tree): 520 583 files changed, 13977 insertions(+), 14719 deletions

[PATCH] net: dsa: mv88e6xxx: add default case to switch

Add default case to switch in order to avoid any chance of using an uninitialized variable _low_, in case s->type does not match any of the listed case values. Addresses-Coverity-ID: 1398130 Suggested-by: Andrew Lunn Signed-off-by: Gustavo A. R. Silva

Re: Implementing Dynamic Rerouting in Kernel

Hi, We do not want to add routes at run time rather i would prefer to have a NetFilter driver which can intercept the packet and forward it to desired interface. On Thu, May 11, 2017 at 9:52 PM, Florian Fainelli wrote: > On 05/11/2017 02:59 AM, Ravish Kumar wrote: >> Hi

[PATCH] net: dsa: mv88e6xxx: add default case to switch

Add default case to switch in order to avoid any chance of using an uninitialized variable _low_, in case s->type does not match any of the listed case values. Addresses-Coverity-ID: 1398130 Suggested-by: Andrew Lunn Signed-off-by: Gustavo A. R. Silva --- drivers/net/dsa/mv88e6xxx/chip.c | 3

Re: Implementing Dynamic Rerouting in Kernel

Hi, We do not want to add routes at run time rather i would prefer to have a NetFilter driver which can intercept the packet and forward it to desired interface. On Thu, May 11, 2017 at 9:52 PM, Florian Fainelli wrote: > On 05/11/2017 02:59 AM, Ravish Kumar wrote: >> Hi Experts, >> >> Need

[GIT PULL] arch/nios2 update for v4.12

Hi Linus Here is nios2 update for v4.12. This including nios2 fixes/enhancements and adding nios2 R2 support. Regards Ley Foon The following changes since commit 13e0988140374123bead1dd27c287354cb95108e:   docs: complete bumping minimal GNU Make version to 3.81 (2017-05-06 18:49:09 -0700)

[GIT PULL] arch/nios2 update for v4.12

Hi Linus Here is nios2 update for v4.12. This including nios2 fixes/enhancements and adding nios2 R2 support. Regards Ley Foon The following changes since commit 13e0988140374123bead1dd27c287354cb95108e:   docs: complete bumping minimal GNU Make version to 3.81 (2017-05-06 18:49:09 -0700)

Re: [PATCH net] net: phy: Call bus->reset() after releasing PHYs from reset

From: Florian Fainelli Date: Thu, 11 May 2017 11:24:16 -0700 > The API convention makes it that a given MDIO bus reset should be able > to access PHY devices in its reset() callback and perform additional > MDIO accesses in order to bring the bus and PHYs in a working

Re: [PATCH net] net: phy: Call bus->reset() after releasing PHYs from reset

From: Florian Fainelli Date: Thu, 11 May 2017 11:24:16 -0700 > The API convention makes it that a given MDIO bus reset should be able > to access PHY devices in its reset() callback and perform additional > MDIO accesses in order to bring the bus and PHYs in a working state. > > Commit

Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

On Fri, 12 May 2017 02:12:10 + "Chen, Xiaoguang" wrote: > Hi Alex and Gerd, > > >-Original Message- > >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > >Behalf Of Alex Williamson > >Sent: Thursday, May 11, 2017 11:45 PM > >To:

Re: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

On Fri, 12 May 2017 02:12:10 + "Chen, Xiaoguang" wrote: > Hi Alex and Gerd, > > >-Original Message- > >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > >Behalf Of Alex Williamson > >Sent: Thursday, May 11, 2017 11:45 PM > >To: Gerd Hoffmann > >Cc: Tian,

[PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

Hi Helgaas, Some AMD GPUs have hardware support for graphics SR-IOV. If the SR-IOV capable GPU is plugged into the SR-IOV incapable platform. It would cause a problem on PCI resource allocation in current Linux kernel. Therefore in order to allow the PF (Physical Function) device of SR-IOV

[PATCH] PCI: Make SR-IOV capable GPU working on the SR-IOV incapable platform

Hi Helgaas, Some AMD GPUs have hardware support for graphics SR-IOV. If the SR-IOV capable GPU is plugged into the SR-IOV incapable platform. It would cause a problem on PCI resource allocation in current Linux kernel. Therefore in order to allow the PF (Physical Function) device of SR-IOV

Re: [net-dsa-mv88e6xxx] question about potential use of uninitialized variable

Hi Andrew, Quoting Andrew Lunn : On Thu, May 11, 2017 at 04:35:37PM -0500, Gustavo A. R. Silva wrote: Hello everybody, While looking into Coverity ID 1398130 I ran into the following piece of code at drivers/net/dsa/mv88e6xxx/chip.c:849: 849static uint64_t

Re: [net-dsa-mv88e6xxx] question about potential use of uninitialized variable

Hi Andrew, Quoting Andrew Lunn : On Thu, May 11, 2017 at 04:35:37PM -0500, Gustavo A. R. Silva wrote: Hello everybody, While looking into Coverity ID 1398130 I ran into the following piece of code at drivers/net/dsa/mv88e6xxx/chip.c:849: 849static uint64_t

Re: [PATCH v5 15/17] dt-bindings: qca7000: append UART interface to binding

On Thu, 11 May 2017 21:12:22 +0200, Michael Heimpold wrote: > Am Mittwoch, 10. Mai 2017, 10:53:26 CEST schrieb Stefan Wahren: > > This merges the serdev binding for the QCA7000 UART driver (Ethernet over > > UART) into the existing document. > > > > Signed-off-by: Stefan Wahren

Re: [PATCH v5 15/17] dt-bindings: qca7000: append UART interface to binding

On Thu, 11 May 2017 21:12:22 +0200, Michael Heimpold wrote: > Am Mittwoch, 10. Mai 2017, 10:53:26 CEST schrieb Stefan Wahren: > > This merges the serdev binding for the QCA7000 UART driver (Ethernet over > > UART) into the existing document. > > > > Signed-off-by: Stefan Wahren > > --- > >

[PATCH] nvmem: rockchip-efuse: add support for rk322x-efuse

This adds the necessary data for handling eFuse on the rk322x. Signed-off-by: Finley Xiao --- Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt | 1 + drivers/nvmem/rockchip-efuse.c | 4 2 files changed, 5 insertions(+) diff

[PATCH] nvmem: rockchip-efuse: add support for rk322x-efuse

This adds the necessary data for handling eFuse on the rk322x. Signed-off-by: Finley Xiao --- Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt | 1 + drivers/nvmem/rockchip-efuse.c | 4 2 files changed, 5 insertions(+) diff --git

[PATCH v2] [media] mtk-mdp: Fix g_/s_selection capture/compose logic

From: Daniel Kurtz Experiments show that the: (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets Signed-off-by: Daniel Kurtz Signed-off-by: Minghsiu Tsai

[PATCH v2] [media] mtk-mdp: Fix g_/s_selection capture/compose logic

From: Daniel Kurtz Experiments show that the: (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets Signed-off-by: Daniel Kurtz Signed-off-by: Minghsiu Tsai Signed-off-by: Houlong Wei --- Changes in v2: . Can not use

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

Hi, > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > lid_init_state=open" > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > > Hi, > > > > > From: Benjamin Tissoires

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

Hi, > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com] > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > lid_init_state=open" > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > > Hi, > > > > > From: Benjamin Tissoires

Re: [net-dsa-mv88e6xxx] question about potential use of uninitialized variable

On Thu, May 11, 2017 at 04:35:37PM -0500, Gustavo A. R. Silva wrote: > > Hello everybody, > > While looking into Coverity ID 1398130 I ran into the following > piece of code at drivers/net/dsa/mv88e6xxx/chip.c:849: > > 849static uint64_t _mv88e6xxx_get_ethtool_stat(struct mv88e6xxx_chip *chip,

Re: [net-dsa-mv88e6xxx] question about potential use of uninitialized variable

On Thu, May 11, 2017 at 04:35:37PM -0500, Gustavo A. R. Silva wrote: > > Hello everybody, > > While looking into Coverity ID 1398130 I ran into the following > piece of code at drivers/net/dsa/mv88e6xxx/chip.c:849: > > 849static uint64_t _mv88e6xxx_get_ethtool_stat(struct mv88e6xxx_chip *chip,

[PATCH v5 3/4] zram: make deduplication feature optional

From: Joonsoo Kim Benefit of deduplication is dependent on the workload so it's not preferable to always enable. Therefore, make it optional in Kconfig and device param. Default is 'off'. This option will be beneficial for users who use the zram as blockdev and stores

[PATCH v5 3/4] zram: make deduplication feature optional

From: Joonsoo Kim Benefit of deduplication is dependent on the workload so it's not preferable to always enable. Therefore, make it optional in Kconfig and device param. Default is 'off'. This option will be beneficial for users who use the zram as blockdev and stores build output to it.

[PATCH v5 2/4] zram: implement deduplication in zram

From: Joonsoo Kim This patch implements deduplication feature in zram. The purpose of this work is naturally to save amount of memory usage by zram. Android is one of the biggest users to use zram as swap and it's really important to save amount of memory usage. There is

[PATCH v5 0/4] zram: implement deduplication in zram

From: Joonsoo Kim <iamjoonsoo@lge.com> Changes from v4 o rebase on next-20170511 o collect Reviewed-by from Sergey Changes from v3 o fix module build problem o make zram_dedup_enabled() statically return false if CONFIG_ZRAM_DEDUP=n Changes from v2 o rebase to latest zram code o

[PATCH v5 1/4] zram: introduce zram_entry to prepare dedup functionality

From: Joonsoo Kim Following patch will implement deduplication functionality in the zram and it requires an indirection layer to manage the life cycle of zsmalloc handle. To prepare that, this patch introduces zram_entry which can be used to manage the life-cycle of

[PATCH v5 4/4] zram: compare all the entries with same checksum for deduplication

From: Joonsoo Kim Until now, we compare just one entry with same checksum when checking duplication since it is the simplest way to implement. However, for the completeness, checking all the entries is better so this patch implement to compare all the entries with same

[PATCH v5 2/4] zram: implement deduplication in zram

From: Joonsoo Kim This patch implements deduplication feature in zram. The purpose of this work is naturally to save amount of memory usage by zram. Android is one of the biggest users to use zram as swap and it's really important to save amount of memory usage. There is a paper that reports

[PATCH v5 0/4] zram: implement deduplication in zram

From: Joonsoo Kim Changes from v4 o rebase on next-20170511 o collect Reviewed-by from Sergey Changes from v3 o fix module build problem o make zram_dedup_enabled() statically return false if CONFIG_ZRAM_DEDUP=n Changes from v2 o rebase to latest zram code o manage alloc/free of the zram_entry

[PATCH v5 1/4] zram: introduce zram_entry to prepare dedup functionality

From: Joonsoo Kim Following patch will implement deduplication functionality in the zram and it requires an indirection layer to manage the life cycle of zsmalloc handle. To prepare that, this patch introduces zram_entry which can be used to manage the life-cycle of zsmalloc handle. Many lines

[PATCH v5 4/4] zram: compare all the entries with same checksum for deduplication

From: Joonsoo Kim Until now, we compare just one entry with same checksum when checking duplication since it is the simplest way to implement. However, for the completeness, checking all the entries is better so this patch implement to compare all the entries with same checksum. Since this event

Re: [PATCH] mm: per-cgroup memory reclaim stats

On Thu, 2017-05-11 at 20:16 +0100, Roman Gushchin wrote: > Track the following reclaim counters for every memory cgroup: > PGREFILL, PGSCAN, PGSTEAL, PGACTIVATE, PGDEACTIVATE, PGLAZYFREE and > PGLAZYFREED. > > These values are exposed using the memory.stats interface of cgroup v2. The changelog

Re: [PATCH] mm: per-cgroup memory reclaim stats

On Thu, 2017-05-11 at 20:16 +0100, Roman Gushchin wrote: > Track the following reclaim counters for every memory cgroup: > PGREFILL, PGSCAN, PGSTEAL, PGACTIVATE, PGDEACTIVATE, PGLAZYFREE and > PGLAZYFREED. > > These values are exposed using the memory.stats interface of cgroup v2. The changelog

[PATCH 2/2] mm: swap: move anonymous THP split logic to vmscan

The add_to_swap aims to allocate swap_space(ie, swap slot and swapcache) so if it fails due to lack of space in case of THP or something(hdd swap but tries THP swapout) *caller* rather than add_to_swap itself should split the THP page and retry it with base page which is more natural. Cc:

[PATCH 1/2] mm: swap: unify swap slot free functions to put_swap_page

Now, get_swap_page takes struct page and allocates swap space according to page size(ie, normal or THP) so it would be more cleaner to introduce put_swap_page which is a counter function of get_swap_page. Then, it calls right swap slot free function depending on page's size. Cc: Johannes Weiner

[PATCH 2/2] mm: swap: move anonymous THP split logic to vmscan

The add_to_swap aims to allocate swap_space(ie, swap slot and swapcache) so if it fails due to lack of space in case of THP or something(hdd swap but tries THP swapout) *caller* rather than add_to_swap itself should split the THP page and retry it with base page which is more natural. Cc:

[PATCH 1/2] mm: swap: unify swap slot free functions to put_swap_page

Now, get_swap_page takes struct page and allocates swap space according to page size(ie, normal or THP) so it would be more cleaner to introduce put_swap_page which is a counter function of get_swap_page. Then, it calls right swap slot free function depending on page's size. Cc: Johannes Weiner

Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

Madhavan Srinivasan writes: >> * in patch 9 should opal_imc_counters_init return something other >>than OPAL_SUCCESS in the case on invalid arguments? Maybe >>OPAL_PARAMETER? (I think you fix this in a later patch anyway?) > > So, init call will

Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

Madhavan Srinivasan writes: >> * in patch 9 should opal_imc_counters_init return something other >>than OPAL_SUCCESS in the case on invalid arguments? Maybe >>OPAL_PARAMETER? (I think you fix this in a later patch anyway?) > > So, init call will return OPAL_PARAMETER for the

Re: [v6 PATCH 07/21] x86/insn-eval: Add utility function to get segment descriptor

On Thu, 2017-05-04 at 13:02 +0200, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 02:51:56PM -0700, Ricardo Neri wrote: > > > > +seg >= > > > > current->active_mm->context.ldt->size)) { > > > > > > ldt->size is the size of the descriptor table but you've shifted seg

Re: [v6 PATCH 07/21] x86/insn-eval: Add utility function to get segment descriptor

On Thu, 2017-05-04 at 13:02 +0200, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 02:51:56PM -0700, Ricardo Neri wrote: > > > > +seg >= > > > > current->active_mm->context.ldt->size)) { > > > > > > ldt->size is the size of the descriptor table but you've shifted seg

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

Hi Alex and Gerd, >-Original Message- >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On >Behalf Of Alex Williamson >Sent: Thursday, May 11, 2017 11:45 PM >To: Gerd Hoffmann >Cc: Tian, Kevin ;

RE: [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

Hi Alex and Gerd, >-Original Message- >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On >Behalf Of Alex Williamson >Sent: Thursday, May 11, 2017 11:45 PM >To: Gerd Hoffmann >Cc: Tian, Kevin ; intel-...@lists.freedesktop.org; linux- >ker...@vger.kernel.org;

Re: [v6 PATCH 08/21] x86/insn-eval: Add utility function to get segment descriptor base address

On Fri, 2017-05-05 at 19:19 +0200, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 03:37:44PM -0700, Ricardo Neri wrote: > > I need a human-readable way of identifying what segment selector (in > > pt_regs, vm86regs or directly reading the segment registers) to use. > > Since there is a segment

Re: [v6 PATCH 08/21] x86/insn-eval: Add utility function to get segment descriptor base address

On Fri, 2017-05-05 at 19:19 +0200, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 03:37:44PM -0700, Ricardo Neri wrote: > > I need a human-readable way of identifying what segment selector (in > > pt_regs, vm86regs or directly reading the segment registers) to use. > > Since there is a segment

Re: [v6 PATCH 08/21] x86/insn-eval: Add utility function to get segment descriptor base address

On Fri, 2017-05-05 at 19:28 +0200, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 03:52:41PM -0700, Ricardo Neri wrote: > > Probably insn_get_seg_base() itself can verify if there are segment > > override prefixes in the struct insn. If yes, use them except for > > specific cases such as CS. >

Re: [v6 PATCH 08/21] x86/insn-eval: Add utility function to get segment descriptor base address

On Fri, 2017-05-05 at 19:28 +0200, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 03:52:41PM -0700, Ricardo Neri wrote: > > Probably insn_get_seg_base() itself can verify if there are segment > > override prefixes in the struct insn. If yes, use them except for > > specific cases such as CS. >

[PATCH 3/5] x86: msr-index.h: fix shifts to ULL results in HWP macros.

From: Len Brown x = 1 ulong_long = x << 32; results in: warning: left shift count >= width of type x = 8 ulong_long = x << 24; results in a sign extended ulong_long Cast x to unsigned long long in these macros to prevent these errors. Signed-off-by: Len Brown

[PATCH 3/5] x86: msr-index.h: fix shifts to ULL results in HWP macros.

From: Len Brown x = 1 ulong_long = x << 32; results in: warning: left shift count >= width of type x = 8 ulong_long = x << 24; results in a sign extended ulong_long Cast x to unsigned long long in these macros to prevent these errors. Signed-off-by: Len Brown ---

[PATCH 5/5] intel_pstate: use updated msr-index.h HWP.EPP values

From: Len Brown intel_pstate exports sysfs attributes for setting and observing HWP.EPP. These attributes use strings to describe 4 operating states, and inside the driver, these strings are mapped to numerical register values. The authorative mapping between the strings

[PATCH 5/5] intel_pstate: use updated msr-index.h HWP.EPP values

From: Len Brown intel_pstate exports sysfs attributes for setting and observing HWP.EPP. These attributes use strings to describe 4 operating states, and inside the driver, these strings are mapped to numerical register values. The authorative mapping between the strings and numerical HWP.EPP

[PATCH 1/5] x86: msr-index.h: define EPB mid-points

From: Len Brown These are currently open-coded into intel_pstate.c Signed-off-by: Len Brown --- arch/x86/include/asm/msr-index.h | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/msr-index.h

Re: [PATCH v7 0/7] Introduce ZONE_CMA

On Thu, May 11, 2017 at 11:13:04AM +0200, Michal Hocko wrote: > On Thu 11-05-17 11:12:43, Joonsoo Kim wrote: > > Sorry for the late response. I was on a vacation. > > > > On Tue, May 02, 2017 at 03:32:29PM +0200, Michal Hocko wrote: > > > On Tue 02-05-17 13:01:32, Joonsoo Kim wrote: > > > > On

[PATCH 1/5] x86: msr-index.h: define EPB mid-points

From: Len Brown These are currently open-coded into intel_pstate.c Signed-off-by: Len Brown --- arch/x86/include/asm/msr-index.h | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index

Re: [PATCH v7 0/7] Introduce ZONE_CMA

On Thu, May 11, 2017 at 11:13:04AM +0200, Michal Hocko wrote: > On Thu 11-05-17 11:12:43, Joonsoo Kim wrote: > > Sorry for the late response. I was on a vacation. > > > > On Tue, May 02, 2017 at 03:32:29PM +0200, Michal Hocko wrote: > > > On Tue 02-05-17 13:01:32, Joonsoo Kim wrote: > > > > On

[GIT PULL] power utilities update

Hi Rafael, Please pull these power utilities patches. The x86_energy_perf_policy(8) utility grows the ability to manage HWP.EPP (and Hardware P-states, in-general), on top of its previous ability to manage EPB. Linux-4.11 grew the ability to disable the cpufreq sub-system entirely with

[PATCH 2/5] x86: msr-index.h: define HWP.EPP values

From: Len Brown The Hardware Performance State request MSR has a field to express the "Energy Performance Preference" (HWP.EPP). Decode that field so the definition may be shared by by the intel_pstate driver and any utilities that decode the same register. Signed-off-by:

[PATCH 4/5] tools/power x86_energy_perf_policy: support HWP.EPP

From: Len Brown x86_energy_perf_policy(8) was created as an example of how the user, or upper-level OS, can manage MSR_IA32_ENERGY_PERF_BIAS (EPB). Hardware consults EPB when it makes internal decisions balancing energy-saving vs performance. For example, should HW quickly

[GIT PULL] power utilities update

Hi Rafael, Please pull these power utilities patches. The x86_energy_perf_policy(8) utility grows the ability to manage HWP.EPP (and Hardware P-states, in-general), on top of its previous ability to manage EPB. Linux-4.11 grew the ability to disable the cpufreq sub-system entirely with

<    1   2   3   4   5   6   7   8   9   10   >