[patch V3 18/28] x86/perf/intel_rapl: Make Knights Landings support functional

The Knights Landings support added the events and the detection case, but then returns 0 without actually initializing the driver. Fixes: 3a2a7797326a4 "perf/x86/intel/rapl: Add support for Knights Landing (KNL)" Signed-off-by: Thomas Gleixner Cc: Dasaratharaman Chandramouli ---

[patch V3 22/28] x86/perf/intel/rapl: Cleanup the printk output

The output is inconsistent. Use a proper pr_fmt prefix and split out the advertisement into a seperate function. Remove the WARN_ON in the failure case. It's pointless as we already know where it failed. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 42

[patch V3 25/28] x86/perf/intel/rapl: Utilize event->pmu_private

Store the pmu in event->pmu_private and use it instead of the per cpu data. Preparatory step to get rid of the per cpu allocations. The usage sites are the perf fast path, so we keep that even after the conversion to per package storage as a cpu to package lookup involves 3 loads versus 1 with the

[patch V3 25/28] x86/perf/intel/rapl: Utilize event->pmu_private

Store the pmu in event->pmu_private and use it instead of the per cpu data. Preparatory step to get rid of the per cpu allocations. The usage sites are the perf fast path, so we keep that even after the conversion to per package storage as a cpu to package lookup involves 3 loads versus 1 with the

[patch V3 23/28] x86/perf/intel/rapl: Refactor code some more

Split out code from init into seperate functions. Tidy up the code and get rid of pointless comments. I wish there would be comments for code which is not obvious Signed-off-by: Thomas Gleixner --- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 61

[patch V3 23/28] x86/perf/intel/rapl: Refactor code some more

Split out code from init into seperate functions. Tidy up the code and get rid of pointless comments. I wish there would be comments for code which is not obvious Signed-off-by: Thomas Gleixner --- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 61 ++-- 1 file

[patch V3 24/28] x86/perf/intel/rapl: Make pmu lock raw

This lock is taken in hard interrupt context even on Preempt-RT. Make it raw so RT does not have to patch it. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) Index:

[patch V3 24/28] x86/perf/intel/rapl: Make pmu lock raw

This lock is taken in hard interrupt context even on Preempt-RT. Make it raw so RT does not have to patch it. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) Index:

[patch V3 28/28] x86/perf/intel/rapl: Make it modular

Add the necessary exit functions so it can be built as a module. Signed-off-by: Thomas Gleixner --- arch/x86/Kconfig.perf | 13 + arch/x86/kernel/cpu/Makefile|4 +++- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 22

[patch V3 28/28] x86/perf/intel/rapl: Make it modular

Add the necessary exit functions so it can be built as a module. Signed-off-by: Thomas Gleixner --- arch/x86/Kconfig.perf | 13 + arch/x86/kernel/cpu/Makefile|4 +++- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 22

[patch V3 26/28] x86/perf/intel/rapl: Convert it to a per package facility

RAPL is a per package facility and we already have a mechanism for a dedicated per package reader. So there is no point to have multiple CPUs doing the same. The current implementation actually starts two timers on two cpus if one does: perf stat -C1,2 -e -e power/energy-pkg which

[patch V3 26/28] x86/perf/intel/rapl: Convert it to a per package facility

RAPL is a per package facility and we already have a mechanism for a dedicated per package reader. So there is no point to have multiple CPUs doing the same. The current implementation actually starts two timers on two cpus if one does: perf stat -C1,2 -e -e power/energy-pkg which

[patch V3 19/28] x86/perf/intel/rapl: Add proper error handling

Like uncore the rapl driver lacks error handling. It leaks memory and leaves the hotplug notifier registered. Add the proper error checks, cleanup the memory and register the hotplug notifier only on success. Signed-off-by: Thomas Gleixner ---

[patch V3 19/28] x86/perf/intel/rapl: Add proper error handling

Like uncore the rapl driver lacks error handling. It leaks memory and leaves the hotplug notifier registered. Add the proper error checks, cleanup the memory and register the hotplug notifier only on success. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/cpu/perf_event_intel_rapl.c | 29

[patch V3 27/28] perf: Export perf_event_sysfs_show

Required to use it in modular perf drivers. Signed-off-by: Thomas Gleixner --- kernel/events/core.c |1 + 1 file changed, 1 insertion(+) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -9335,6 +9335,7 @@ ssize_t perf_event_sysfs_show(struct dev return

[patch V3 27/28] perf: Export perf_event_sysfs_show

Required to use it in modular perf drivers. Signed-off-by: Thomas Gleixner --- kernel/events/core.c |1 + 1 file changed, 1 insertion(+) --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -9335,6 +9335,7 @@ ssize_t perf_event_sysfs_show(struct dev return 0; }

[patch V3 13/28] x86/perf/intel_uncore: Clear all hardware state on exit

The only missing bit is to completely clear the hardware state on failure exit. This is now a pretty simple exercise. Undo the box->init_box() setup on all packages which have been initialized so far. Signed-off-by: Thomas Gleixner ---

[patch V3 13/28] x86/perf/intel_uncore: Clear all hardware state on exit

The only missing bit is to completely clear the hardware state on failure exit. This is now a pretty simple exercise. Undo the box->init_box() setup on all packages which have been initialized so far. Signed-off-by: Thomas Gleixner --- arch/x86/kernel/cpu/perf_event_intel_uncore.c | 26

Re: [PATCH] nvdimm: use 'u64' for pfn flags

On Mon, Feb 22, 2016 at 1:58 PM, Arnd Bergmann wrote: > A recent bugfix changed pfn_t to always be 64-bit wide, but did not > change the code in pmem.c, which is now broken on 32-bit architectures > as reported by gcc: > > In file included from ../drivers/nvdimm/pmem.c:28:0: >

Re: [PATCH] nvdimm: use 'u64' for pfn flags

On Mon, Feb 22, 2016 at 1:58 PM, Arnd Bergmann wrote: > A recent bugfix changed pfn_t to always be 64-bit wide, but did not > change the code in pmem.c, which is now broken on 32-bit architectures > as reported by gcc: > > In file included from ../drivers/nvdimm/pmem.c:28:0: >

Re: [PATCH 08/10] x86/xsaves: Fix PTRACE frames for XSAVES

On 02/22/2016 12:48 PM, Yu-cheng Yu wrote: > It should have been: > > xsave->header.xfeatures = xfeatures | > (xsave->header.xfeatures & XFEATURE_MASK_SUPERVISOR); > > I'll fix it. Can we break it out to make it more clear? /* * The state that came in from userspace was

Re: [PATCH 08/10] x86/xsaves: Fix PTRACE frames for XSAVES

On 02/22/2016 12:48 PM, Yu-cheng Yu wrote: > It should have been: > > xsave->header.xfeatures = xfeatures | > (xsave->header.xfeatures & XFEATURE_MASK_SUPERVISOR); > > I'll fix it. Can we break it out to make it more clear? /* * The state that came in from userspace was

Re: [PATCH v2 3/3] vfs: Use per-cpu list for superblock's inode list

On Tue 23-02-16 08:08:14, Dave Chinner wrote: > On Mon, Feb 22, 2016 at 02:04:35PM +0100, Jan Kara wrote: > > On Mon 22-02-16 13:12:22, Peter Zijlstra wrote: > > > On Mon, Feb 22, 2016 at 12:54:35PM +0100, Jan Kara wrote: > > > > > Also, I think fsnotify_unmount_inodes() (as per mainline) is

[ANNOUNCE] Git v2.7.2

The latest maintenance release Git v2.7.2 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.7.2' tag and the 'maint' branch that the tag points at: url =

Re: [PATCH v2 3/3] vfs: Use per-cpu list for superblock's inode list

On Tue 23-02-16 08:08:14, Dave Chinner wrote: > On Mon, Feb 22, 2016 at 02:04:35PM +0100, Jan Kara wrote: > > On Mon 22-02-16 13:12:22, Peter Zijlstra wrote: > > > On Mon, Feb 22, 2016 at 12:54:35PM +0100, Jan Kara wrote: > > > > > Also, I think fsnotify_unmount_inodes() (as per mainline) is

[ANNOUNCE] Git v2.7.2

The latest maintenance release Git v2.7.2 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.7.2' tag and the 'maint' branch that the tag points at: url =

Re: [PATCHv2] clk: socfpga: allow for multiple parents on Arria10 periph clocks

On 02/22, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > There are some Arria10 clocks of type "altr,socfpga-a10-perip-clk" that can > have multiple parents. Fix up the __socfpga_periph_init() to call > of_clk_parent_fill() that will return the

Re: [PATCHv2] clk: socfpga: allow for multiple parents on Arria10 periph clocks

On 02/22, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > There are some Arria10 clocks of type "altr,socfpga-a10-perip-clk" that can > have multiple parents. Fix up the __socfpga_periph_init() to call > of_clk_parent_fill() that will return the appropriate number of parents. > >

Re: [PATCH] clk: socfpga: allow for multiple parents on Arria10 periph clocks

On 02/22/2016 03:50 PM, Stephen Boyd wrote: > > Oops, spoke too soon: > > drivers/clk/socfpga/clk-periph-a10.c:113:27: warning: incorrect type in > assignment (different base types) > drivers/clk/socfpga/clk-periph-a10.c:113:27:expected char const *const > *[assigned] parent_names >

Re: [PATCH] clk: socfpga: allow for multiple parents on Arria10 periph clocks

On 02/22/2016 03:50 PM, Stephen Boyd wrote: > > Oops, spoke too soon: > > drivers/clk/socfpga/clk-periph-a10.c:113:27: warning: incorrect type in > assignment (different base types) > drivers/clk/socfpga/clk-periph-a10.c:113:27:expected char const *const > *[assigned] parent_names >

Re: [PATCH v4 1/1] ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list

On Fri, Feb 19, 2016 at 07:34:18PM -0600, John Dahlstrom wrote: > Some Lenovo ideapad models lack a physical rfkill switch. > On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK, > ideapad-laptop would wrongly report all radios as blocked by > hardware which caused wireless network

Re: [PATCH v4 1/1] ideapad-laptop: Add ideapad Y700 (15) to the no_hw_rfkill DMI list

On Fri, Feb 19, 2016 at 07:34:18PM -0600, John Dahlstrom wrote: > Some Lenovo ideapad models lack a physical rfkill switch. > On Lenovo models ideapad Y700 Touch-15ISK and ideapad Y700-15ISK, > ideapad-laptop would wrongly report all radios as blocked by > hardware which caused wireless network

Re: [PATCH] clk: socfpga: allow for multiple parents on Arria10 periph clocks

Hi Dinh, [auto build test WARNING on clk/clk-next] [also build test WARNING on v4.5-rc5 next-20160222] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/dinguyen-opensource-altera-com/clk

Re: [PATCH] clk: socfpga: allow for multiple parents on Arria10 periph clocks

Hi Dinh, [auto build test WARNING on clk/clk-next] [also build test WARNING on v4.5-rc5 next-20160222] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/dinguyen-opensource-altera-com/clk

Re: [PATCHv8 0/5] Driver for new "VMD" device

On Wed, Jan 20, 2016 at 04:01:11PM -0600, Bjorn Helgaas wrote: > On Sat, Jan 16, 2016 at 02:19:38PM -0800, Veal, Bryan E. wrote: > > On Fri, Jan 15, 2016 at 03:49:02PM -0600, Bjorn Helgaas wrote: > > > Even though you found this issue before posting the RFC code, I assume > > > the issue is still

Re: [PATCHv8 0/5] Driver for new "VMD" device

On Wed, Jan 20, 2016 at 04:01:11PM -0600, Bjorn Helgaas wrote: > On Sat, Jan 16, 2016 at 02:19:38PM -0800, Veal, Bryan E. wrote: > > On Fri, Jan 15, 2016 at 03:49:02PM -0600, Bjorn Helgaas wrote: > > > Even though you found this issue before posting the RFC code, I assume > > > the issue is still

Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT

On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote: > > > On 22/02/16 05:32, Bjorn Andersson wrote: > >On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set > >to be able to do DMA allocations, so use the of_dma_configure() helper > >to populate the dma properties and

Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT

On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote: > > > On 22/02/16 05:32, Bjorn Andersson wrote: > >On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set > >to be able to do DMA allocations, so use the of_dma_configure() helper > >to populate the dma properties and

[PATCH] xen/x86: Zero out .bss for PV guests

Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't excecute that early code they should do it too. (Since we introduce macros for specifying 32- and 64-bit registers we can get rid of ifdefs in startup_xen()) Signed-off-by: Boris Ostrovsky ---

[PATCH] xen/x86: Zero out .bss for PV guests

Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't excecute that early code they should do it too. (Since we introduce macros for specifying 32- and 64-bit registers we can get rid of ifdefs in startup_xen()) Signed-off-by: Boris Ostrovsky --- arch/x86/xen/xen-head.S |

Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test

On 02/22/2016 11:27 AM, Kees Cook wrote: On Fri, Feb 19, 2016 at 3:07 PM, Laura Abbott wrote: On 02/19/2016 02:19 PM, Kees Cook wrote: On Fri, Feb 19, 2016 at 2:11 PM, Laura Abbott wrote: On 02/19/2016 11:12 AM, Kees Cook wrote: On Thu, Feb 18,

Re: [PATCHv2] lkdtm: Add READ_AFTER_FREE test

On 02/22/2016 11:27 AM, Kees Cook wrote: On Fri, Feb 19, 2016 at 3:07 PM, Laura Abbott wrote: On 02/19/2016 02:19 PM, Kees Cook wrote: On Fri, Feb 19, 2016 at 2:11 PM, Laura Abbott wrote: On 02/19/2016 11:12 AM, Kees Cook wrote: On Thu, Feb 18, 2016 at 5:15 PM, Laura Abbott wrote:

[PATCH V2 01/13] block: estimate disk performance

weight based blk-throttling can use the estimated performance to calculate cgroup bandwidth/IOPS. That said we never can't get accurate disk performance in a complex workload, a roughly estimation is enough. One issue is workload might not send enough IO to make disk 100% busy. The calculation

[PATCH V2 07/13] blk-throttle: add interface for proporation based throttle

There is throttle.mode_device interface. By default blk-throttle is in NONE mode. Setting original bps/iops limit wil change mode to THROTTLE automatically, user doesn't need to configure the mode, which is for backward compabitbility. To use proporation based throttle, user must configure device

[PATCH V2 03/13] blk-throttle: add abstract to index data

For throttle, we have separate data to track READ/WRITE IO. For weight based throttle, we combine read/write bandwidth and check combined bandwidth. Separate throttle doesn't work, because it's possible one cgroup only does READ and the other only does WRITE. This patch adds an abstract to index

[PATCH V2 01/13] block: estimate disk performance

weight based blk-throttling can use the estimated performance to calculate cgroup bandwidth/IOPS. That said we never can't get accurate disk performance in a complex workload, a roughly estimation is enough. One issue is workload might not send enough IO to make disk 100% busy. The calculation

[PATCH V2 07/13] blk-throttle: add interface for proporation based throttle

There is throttle.mode_device interface. By default blk-throttle is in NONE mode. Setting original bps/iops limit wil change mode to THROTTLE automatically, user doesn't need to configure the mode, which is for backward compabitbility. To use proporation based throttle, user must configure device

[PATCH V2 03/13] blk-throttle: add abstract to index data

For throttle, we have separate data to track READ/WRITE IO. For weight based throttle, we combine read/write bandwidth and check combined bandwidth. Separate throttle doesn't work, because it's possible one cgroup only does READ and the other only does WRITE. This patch adds an abstract to index

[PATCH V2 05/13] blk-throttling: detect inactive cgroup

We don't have a tree to maintain active cgroups. If a cgroup is inactive for some time, it should be excluded from bandwidth calculation. Otherwise we will only assign partial bandwidth to active cgroups, active cgroups will dispatch less IO, the estimated queue bandwidth drops, which will cause

[PATCH V2 05/13] blk-throttling: detect inactive cgroup

We don't have a tree to maintain active cgroups. If a cgroup is inactive for some time, it should be excluded from bandwidth calculation. Otherwise we will only assign partial bandwidth to active cgroups, active cgroups will dispatch less IO, the estimated queue bandwidth drops, which will cause

[PATCH V2 11/13] blk-throttle: shrink cgroup share if its target is overestimated

cgroup's share could be over estimated. For example, cg1 gets 20% share, cg2 gets 80% share. 1. disk max bps 200, cgroup has no limitation cg1 bps == 40, cg2 bps = 160 2. disk max bps 200, cg2 can only dispatch 10 bps cg1 bps == 190 (not 2.5), cg2 bps == 10 cg2 can't use its share, so we must

[PATCH V2 11/13] blk-throttle: shrink cgroup share if its target is overestimated

cgroup's share could be over estimated. For example, cg1 gets 20% share, cg2 gets 80% share. 1. disk max bps 200, cgroup has no limitation cg1 bps == 40, cg2 bps = 160 2. disk max bps 200, cg2 can only dispatch 10 bps cg1 bps == 190 (not 2.5), cg2 bps == 10 cg2 can't use its share, so we must

[PATCH V2 00/13] block-throttle: proportional throttle

Hi, Currently we have 2 iocontrollers. blk-throttling is bandwidth/iops based. CFQ is weight based. It would be great there is a unified iocontroller for the two. And blk-mq doesn't support ioscheduler, leaving blk-throttling the only option for blk-mq. It's time to have a scalable iocontroller

[PATCH V2 02/13] blk-throttle: cleanup io cost related stuff

Move io cost related data to separate data structure and corresponding code to separate functions. In the future, we will seek more advanced algorithm to measure IO cost. The separation makes things easier. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 230

[PATCH V2 00/13] block-throttle: proportional throttle

Hi, Currently we have 2 iocontrollers. blk-throttling is bandwidth/iops based. CFQ is weight based. It would be great there is a unified iocontroller for the two. And blk-mq doesn't support ioscheduler, leaving blk-throttling the only option for blk-mq. It's time to have a scalable iocontroller

[PATCH V2 02/13] blk-throttle: cleanup io cost related stuff

Move io cost related data to separate data structure and corresponding code to separate functions. In the future, we will seek more advanced algorithm to measure IO cost. The separation makes things easier. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 230

[PATCH V2 13/13] blk-throttle: detect wrong shrink

Last patch detects wrong shrink for some cases, but not all. Let's have an example. cg1 gets 20% share, cg2 gets 80% share. disk max bps 100, cgroup can only dispatch 80 bps cg1 bps = 20, cg2 bps = 80 This should be stable state, but we don't know about it. As we assign extra bps to queue, we

[PATCH V2 04/13] blk-throttle: weight based throttling

We know total bandwidth of a disk and can calculate cgroup's bandwidth percentage against disk bandwidth according to its weight. We can easily calculate cgroup bandwidth. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 160 +--

[PATCH V2 13/13] blk-throttle: detect wrong shrink

Last patch detects wrong shrink for some cases, but not all. Let's have an example. cg1 gets 20% share, cg2 gets 80% share. disk max bps 100, cgroup can only dispatch 80 bps cg1 bps = 20, cg2 bps = 80 This should be stable state, but we don't know about it. As we assign extra bps to queue, we

[PATCH V2 04/13] blk-throttle: weight based throttling

We know total bandwidth of a disk and can calculate cgroup's bandwidth percentage against disk bandwidth according to its weight. We can easily calculate cgroup bandwidth. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 160 +-- 1 file

[PATCH V2 08/13] blk-throttle: add cgroup2 interface

Example usage of the cgroup2 interface: $echo "+io" > /sys/fs/cgroup/cgroup.subtree_control set bandwidth based proporation mode $echo "8:0 weight_bw" > /sys/fs/cgroup/io.throttle.mode_device $mkdir /sys/fs/cgroup/test set cgroup weight $echo "8:0 200" > /sys/fs/cgroup/test/io.throttle.weight

[PATCH V2 08/13] blk-throttle: add cgroup2 interface

Example usage of the cgroup2 interface: $echo "+io" > /sys/fs/cgroup/cgroup.subtree_control set bandwidth based proporation mode $echo "8:0 weight_bw" > /sys/fs/cgroup/io.throttle.mode_device $mkdir /sys/fs/cgroup/test set cgroup weight $echo "8:0 200" > /sys/fs/cgroup/test/io.throttle.weight

[PATCH V2 10/13] blk-throttle: over estimate bandwidth

If we don't dispatch enough requests, disk can't reach the max bandwidth. As we don't know the max bandwidth, we over estimate the bandwidth and dispatch more requests. This way the disk can reach the max bandwidth slowly. The downside is this can introduce fairness issue, but since we only over

[PATCH V2 10/13] blk-throttle: over estimate bandwidth

If we don't dispatch enough requests, disk can't reach the max bandwidth. As we don't know the max bandwidth, we over estimate the bandwidth and dispatch more requests. This way the disk can reach the max bandwidth slowly. The downside is this can introduce fairness issue, but since we only over

[PATCH V2 12/13] blk-throttle: restore shrinked cgroup share

If a cgroup share gets shrinked but the cgroup hits its limit, the shrink isn't optimal, we restore its original share. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/block/blk-throttle.c

[PATCH V2 12/13] blk-throttle: restore shrinked cgroup share

If a cgroup share gets shrinked but the cgroup hits its limit, the shrink isn't optimal, we restore its original share. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/block/blk-throttle.c

[PATCH V2 06/13] blk-throttle: add per-cgroup data

Currently we only per-cgroup per-queue data. This adds per-cgroup data (cgroup weight). Changing the per-cgroup weight will change all per-cgroup per-queue weight. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 47 ++- 1 file

[PATCH V2 09/13] blk-throttle: add trace for new proporation throttle

The trace log is very helpful to track bug and performance issues. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 9 + 1 file changed, 9 insertions(+) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index 01ca04e..68e2598 100644 --- a/block/blk-throttle.c

[PATCH V2 06/13] blk-throttle: add per-cgroup data

Currently we only per-cgroup per-queue data. This adds per-cgroup data (cgroup weight). Changing the per-cgroup weight will change all per-cgroup per-queue weight. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 47 ++- 1 file changed, 46

[PATCH V2 09/13] blk-throttle: add trace for new proporation throttle

The trace log is very helpful to track bug and performance issues. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 9 + 1 file changed, 9 insertions(+) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index 01ca04e..68e2598 100644 --- a/block/blk-throttle.c +++

[PATCHv2] clk: socfpga: allow for multiple parents on Arria10 periph clocks

From: Dinh Nguyen There are some Arria10 clocks of type "altr,socfpga-a10-perip-clk" that can have multiple parents. Fix up the __socfpga_periph_init() to call of_clk_parent_fill() that will return the appropriate number of parents. Also, update

[PATCHv2] clk: socfpga: allow for multiple parents on Arria10 periph clocks

From: Dinh Nguyen There are some Arria10 clocks of type "altr,socfpga-a10-perip-clk" that can have multiple parents. Fix up the __socfpga_periph_init() to call of_clk_parent_fill() that will return the appropriate number of parents. Also, update __socfpga_gate_init() to call

[PATCH] nvdimm: use 'u64' for pfn flags

A recent bugfix changed pfn_t to always be 64-bit wide, but did not change the code in pmem.c, which is now broken on 32-bit architectures as reported by gcc: In file included from ../drivers/nvdimm/pmem.c:28:0: drivers/nvdimm/pmem.c: In function 'pmem_alloc': include/linux/pfn_t.h:15:17: error:

[PATCH] nvdimm: use 'u64' for pfn flags

A recent bugfix changed pfn_t to always be 64-bit wide, but did not change the code in pmem.c, which is now broken on 32-bit architectures as reported by gcc: In file included from ../drivers/nvdimm/pmem.c:28:0: drivers/nvdimm/pmem.c: In function 'pmem_alloc': include/linux/pfn_t.h:15:17: error:

[PATCH] btrfs: avoid uninitialized variable warning

With CONFIG_SMP and CONFIG_PREEMPT both disabled, gcc decides to partially inline the get_state_failrec() function but cannot figure out that means the failrec pointer is always valid if the function returns success, which causes a harmless warning: fs/btrfs/extent_io.c: In function

[PATCH] btrfs: avoid uninitialized variable warning

With CONFIG_SMP and CONFIG_PREEMPT both disabled, gcc decides to partially inline the get_state_failrec() function but cannot figure out that means the failrec pointer is always valid if the function returns success, which causes a harmless warning: fs/btrfs/extent_io.c: In function

Re: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for stm32 chip

On 22 February 2016 at 15:50, Alexandre Torgue wrote: > 2016-02-13 14:48 GMT+01:00 Joachim Eastwood : >> On 3 February 2016 at 15:54, Alexandre TORGUE >> wrote: >>> + plat_dat->bsp_priv = dwmac; >>> +

Re: [PATCH 1/4] net: ethernet: dwmac: add Ethernet glue logic for stm32 chip

On 22 February 2016 at 15:50, Alexandre Torgue wrote: > 2016-02-13 14:48 GMT+01:00 Joachim Eastwood : >> On 3 February 2016 at 15:54, Alexandre TORGUE >> wrote: >>> + plat_dat->bsp_priv = dwmac; >>> + plat_dat->init = stm32_dwmac_init; >>> + plat_dat->exit = stm32_dwmac_exit;

[PATCH] fs: crypto: add CONFIG_BLOCK dependency

The newly added generic crypto abstraction for file systems operates on 'struct bio' objects, which do not exist when CONFIG_BLOCK is disabled: fs/crypto/crypto.c: In function 'fscrypt_zeroout_range': fs/crypto/crypto.c:308:9: error: implicit declaration of function 'bio_alloc'

[PATCH] fs: crypto: add CONFIG_BLOCK dependency

The newly added generic crypto abstraction for file systems operates on 'struct bio' objects, which do not exist when CONFIG_BLOCK is disabled: fs/crypto/crypto.c: In function 'fscrypt_zeroout_range': fs/crypto/crypto.c:308:9: error: implicit declaration of function 'bio_alloc'

Re: [PATCH] clk: socfpga: allow for multiple parents on Arria10 periph clocks

On 02/22, Stephen Boyd wrote: > On 02/22, dingu...@opensource.altera.com wrote: > > From: Dinh Nguyen > > > > There are some Arria10 clocks of type "altr,socfpga-a10-perip-clk" that can > > have multiple parents. Fix up the __socfpga_periph_init() to call > >

Re: [PATCH] clk: socfpga: allow for multiple parents on Arria10 periph clocks

On 02/22, Stephen Boyd wrote: > On 02/22, dingu...@opensource.altera.com wrote: > > From: Dinh Nguyen > > > > There are some Arria10 clocks of type "altr,socfpga-a10-perip-clk" that can > > have multiple parents. Fix up the __socfpga_periph_init() to call > > of_clk_parent_fill() that will

Re: [PATCH] clk: socfpga: allow for multiple parents on Arria10 periph clocks

On 02/22, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > There are some Arria10 clocks of type "altr,socfpga-a10-perip-clk" that can > have multiple parents. Fix up the __socfpga_periph_init() to call > of_clk_parent_fill() that will return the

Re: [PATCH] clk: socfpga: allow for multiple parents on Arria10 periph clocks

On 02/22, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > There are some Arria10 clocks of type "altr,socfpga-a10-perip-clk" that can > have multiple parents. Fix up the __socfpga_periph_init() to call > of_clk_parent_fill() that will return the appropriate number of parents. > >

[PATCH] ubi: Fix early logging

We must not use ubi_* log functions before the ubi_device struct is initialized. And while we are here, define a sane pr_fmt and add new lines to existing pr_* calls. Fixes: 32608703 ("UBI: Extend UBI layer debug/messaging capabilities") Signed-off-by: Richard Weinberger ---

[PATCH] ubi: Fix early logging

We must not use ubi_* log functions before the ubi_device struct is initialized. And while we are here, define a sane pr_fmt and add new lines to existing pr_* calls. Fixes: 32608703 ("UBI: Extend UBI layer debug/messaging capabilities") Signed-off-by: Richard Weinberger ---

Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks

On Mon, Feb 22, 2016 at 11:52 AM, Peter Zijlstra wrote: > On Fri, Feb 19, 2016 at 09:28:23AM -0800, Steve Muckle wrote: >> On 02/19/2016 08:42 AM, Srinivas Pandruvada wrote: >> > We did experiments using util/max in intel_pstate. For some benchmarks >> > there were

Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks

On Mon, Feb 22, 2016 at 11:52 AM, Peter Zijlstra wrote: > On Fri, Feb 19, 2016 at 09:28:23AM -0800, Steve Muckle wrote: >> On 02/19/2016 08:42 AM, Srinivas Pandruvada wrote: >> > We did experiments using util/max in intel_pstate. For some benchmarks >> > there were regression of 4 to 5%, for some

Re: [PATCH] Documentation/memory-barriers: fix wrong comment in example

On Tue, Feb 23, 2016 at 1:33 AM, Paul E. McKenney wrote: > On Mon, Feb 22, 2016 at 11:16:39AM +, David Howells wrote: >> SeongJae Park wrote: >> >> > From f7b5677790771599f418f1d95536935be971ae86 Mon Sep 17 00:00:00 2001 >> > From: SeongJae

Re: [PATCH] Documentation/memory-barriers: fix wrong comment in example

On Tue, Feb 23, 2016 at 1:33 AM, Paul E. McKenney wrote: > On Mon, Feb 22, 2016 at 11:16:39AM +, David Howells wrote: >> SeongJae Park wrote: >> >> > From f7b5677790771599f418f1d95536935be971ae86 Mon Sep 17 00:00:00 2001 >> > From: SeongJae Park >> > Date: Mon, 22 Feb 2016 19:26:18 +0900 >>

Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks

On Mon, Feb 22, 2016 at 10:42 AM, Juri Lelli wrote: > Hi Rafael, > > On 19/02/16 23:26, Rafael J. Wysocki wrote: >> On Friday, February 19, 2016 05:26:04 PM Juri Lelli wrote: >> > Hi Srinivas, [cut] >> --- >> From: Rafael J. Wysocki >> Subject:

Re: [PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks

On Mon, Feb 22, 2016 at 10:42 AM, Juri Lelli wrote: > Hi Rafael, > > On 19/02/16 23:26, Rafael J. Wysocki wrote: >> On Friday, February 19, 2016 05:26:04 PM Juri Lelli wrote: >> > Hi Srinivas, [cut] >> --- >> From: Rafael J. Wysocki >> Subject: [PATCH] cpufreq: Rework the scheduler hooks for

Re: [PATCH 1/1] of/overlay: of overlay callbacks

On Mon, 22 Feb 2016, Pantelis Antoniou wrote: > Hi Rob, > > > On Feb 22, 2016, at 04:55 , Rob Herring wrote: > > > > On Wed, Feb 17, 2016 at 11:41:25AM -0600, Alan Tull wrote: > >> Add overlay callback functionality. > >> > >> When DT overlays are being added, some

Re: [PATCH 1/1] of/overlay: of overlay callbacks

On Mon, 22 Feb 2016, Pantelis Antoniou wrote: > Hi Rob, > > > On Feb 22, 2016, at 04:55 , Rob Herring wrote: > > > > On Wed, Feb 17, 2016 at 11:41:25AM -0600, Alan Tull wrote: > >> Add overlay callback functionality. > >> > >> When DT overlays are being added, some drivers/subsystems > >>

Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

Am 2016-02-22 um 20:10 schrieb Takashi Iwai: > On Mon, 22 Feb 2016 19:58:18 +0100, > Martin Kepplinger wrote: >> >> Am 2016-02-22 um 15:12 schrieb Takashi Iwai: >>> On Mon, 22 Feb 2016 15:02:56 +0100, >>> Martin Kepplinger wrote: > And how about my questions in the previous mail? Does >

Re: [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

Am 2016-02-22 um 20:10 schrieb Takashi Iwai: > On Mon, 22 Feb 2016 19:58:18 +0100, > Martin Kepplinger wrote: >> >> Am 2016-02-22 um 15:12 schrieb Takashi Iwai: >>> On Mon, 22 Feb 2016 15:02:56 +0100, >>> Martin Kepplinger wrote: > And how about my questions in the previous mail? Does >

[PATCH] drm/layerscape: reduce excessive stack usage

The fsl-dcu driver copies a drm_mode_config object to its stack but then only accesses a single member (dpms_property) once. The data structure is large enough to trigger a warning about the amount of kernel stack being used: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c: In function

[PATCH] drm/layerscape: reduce excessive stack usage

The fsl-dcu driver copies a drm_mode_config object to its stack but then only accesses a single member (dpms_property) once. The data structure is large enough to trigger a warning about the amount of kernel stack being used: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c: In function

Re: [PATCH 3/4] sched/deadline: Tracepoints for deadline scheduler

On Mon, Feb 22, 2016 at 12:48:54PM -0500, Steven Rostedt wrote: > > As it stands, the existing tracepoint have already been an ABI > > trainwreck, why would I want to add more? > > Yes, this may become a type of ABI, but even the sched switch > tracepoints haven't been that bad. Has it really

Re: [PATCH 3/4] sched/deadline: Tracepoints for deadline scheduler

On Mon, Feb 22, 2016 at 12:48:54PM -0500, Steven Rostedt wrote: > > As it stands, the existing tracepoint have already been an ABI > > trainwreck, why would I want to add more? > > Yes, this may become a type of ABI, but even the sched switch > tracepoints haven't been that bad. Has it really

<    4   5   6   7   8   9   10   11   12   13   >