Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

* Paul E. McKenney wrote: > On Sun, Jan 15, 2017 at 08:11:23AM +0100, Ingo Molnar wrote: > > > > * Paul E. McKenney wrote: > > > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > > > index 357b32aaea48..5fdfe874229e

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

* Paul E. McKenney wrote: > On Sun, Jan 15, 2017 at 08:11:23AM +0100, Ingo Molnar wrote: > > > > * Paul E. McKenney wrote: > > > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > > > index 357b32aaea48..5fdfe874229e 100644 > > > --- a/include/linux/rcupdate.h > > > +++

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

On Sun, Jan 15, 2017 at 08:11:23AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > > index 357b32aaea48..5fdfe874229e 100644 > > --- a/include/linux/rcupdate.h > > +++

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

On Sun, Jan 15, 2017 at 08:11:23AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > > index 357b32aaea48..5fdfe874229e 100644 > > --- a/include/linux/rcupdate.h > > +++ b/include/linux/rcupdate.h > > @@ -1175,11

[PATCH] drivers: staging: rtl8188eu: include: Removed unnecssary defined macros

Removed macros not in use. Signed-off-by: Kartikey Singh --- drivers/staging/rtl8188eu/include/wifi.h | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/staging/rtl8188eu/include/wifi.h b/drivers/staging/rtl8188eu/include/wifi.h

[PATCH] drivers: staging: rtl8188eu: include: Removed unnecssary defined macros

Removed macros not in use. Signed-off-by: Kartikey Singh --- drivers/staging/rtl8188eu/include/wifi.h | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/staging/rtl8188eu/include/wifi.h b/drivers/staging/rtl8188eu/include/wifi.h index 9e08e68..9c9c334

RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

> Subject: Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for > SPT > and newer > > On Sat, Jan 14, 2017 at 08:27:31PM +0100, Paul Menzel wrote: > > Dear Greg, > > > > > > On 2017-01-13 14:00, Greg Kroah-Hartman wrote: > > > On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel

RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

> Subject: Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for > SPT > and newer > > On Sat, Jan 14, 2017 at 08:27:31PM +0100, Paul Menzel wrote: > > Dear Greg, > > > > > > On 2017-01-13 14:00, Greg Kroah-Hartman wrote: > > > On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

Hi Jaewon, with all comments above, some of my concerns. On Mon, Dec 26, 2016 at 01:18:11PM +0900, Jaewon Kim wrote: > There was no bitmap API which returns both next zero index and size of zeros > from that index. Yes, there is. Most probably because this function is not needed. Typical

Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size

Hi Jaewon, with all comments above, some of my concerns. On Mon, Dec 26, 2016 at 01:18:11PM +0900, Jaewon Kim wrote: > There was no bitmap API which returns both next zero index and size of zeros > from that index. Yes, there is. Most probably because this function is not needed. Typical

[PATCH] Drivers: staging: rtl8192e: style fix, octal file permissions

Changed file permissions to octal. Found with checkpatch. Signed-off-by: Derek Robson --- drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c

[PATCH] Drivers: staging: rtl8192e: style fix, octal file permissions

Changed file permissions to octal. Found with checkpatch. Signed-off-by: Derek Robson --- drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

* Paul E. McKenney wrote: > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > index 357b32aaea48..5fdfe874229e 100644 > --- a/include/linux/rcupdate.h > +++ b/include/linux/rcupdate.h > @@ -1175,11 +1175,11 @@ do { \ > * if the UNLOCK and LOCK are

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

* Paul E. McKenney wrote: > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h > index 357b32aaea48..5fdfe874229e 100644 > --- a/include/linux/rcupdate.h > +++ b/include/linux/rcupdate.h > @@ -1175,11 +1175,11 @@ do { \ > * if the UNLOCK and LOCK are executed by the same CPU or

Re: [PATCH v6 2/3] input: tm2-touchkey: Add touchkey driver support for TM2

Hi Jaechul, On Mon, Jan 09, 2017 at 04:22:14PM +0900, Jaechul Lee wrote: > +static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid) > +{ > + struct tm2_touchkey_data *touchkey = devid; > + u32 data; > + > + data = i2c_smbus_read_byte_data(touchkey->client, > +

Re: [PATCH v6 2/3] input: tm2-touchkey: Add touchkey driver support for TM2

Hi Jaechul, On Mon, Jan 09, 2017 at 04:22:14PM +0900, Jaechul Lee wrote: > +static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid) > +{ > + struct tm2_touchkey_data *touchkey = devid; > + u32 data; > + > + data = i2c_smbus_read_byte_data(touchkey->client, > +

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

* Paul E. McKenney wrote: > > > + */ > > > +#ifdef CONFIG_PPC > > > +#define smp_mb__after_unlock_lock() smp_mb() /* Full ordering for > > > lock. */ > > > +#else /* #ifdef CONFIG_PPC */ > > > +#define smp_mb__after_unlock_lock() do { } while (0) > > >

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

* Paul E. McKenney wrote: > > > + */ > > > +#ifdef CONFIG_PPC > > > +#define smp_mb__after_unlock_lock() smp_mb() /* Full ordering for > > > lock. */ > > > +#else /* #ifdef CONFIG_PPC */ > > > +#define smp_mb__after_unlock_lock() do { } while (0) > > > +#endif /* #else #ifdef

make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.

Hi Rich, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f4d3935e4f4884ba80561db5549394afb8eef8f7 commit: 190fe191cfbead9fe089453dd092869c9469c6d4 sh: add support for linking a builtin device tree blob in the

make[2]: *** No rule to make target 'arch/sh/boot/dts/.dtb.o', needed by 'arch/sh/boot/dts/built-in.o'.

Hi Rich, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f4d3935e4f4884ba80561db5549394afb8eef8f7 commit: 190fe191cfbead9fe089453dd092869c9469c6d4 sh: add support for linking a builtin device tree blob in the

Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

On 2017-01-12 Michal Hocko wrote: > On Wed 11-01-17 16:52:32, Trevor Cordes wrote: > [...] > > I'm not sure how I can tell if my bug is because of memcgs so here > > is a full first oom example (attached). > > 4.7 kernel doesn't contain 71c799f4982d ("mm: add per-zone lru list > stat") so the

Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

On 2017-01-12 Michal Hocko wrote: > On Wed 11-01-17 16:52:32, Trevor Cordes wrote: > [...] > > I'm not sure how I can tell if my bug is because of memcgs so here > > is a full first oom example (attached). > > 4.7 kernel doesn't contain 71c799f4982d ("mm: add per-zone lru list > stat") so the

Re: [patch v2] mm, memcg: do not retry precharge charges

On Sat, 14 Jan 2017, Johannes Weiner wrote: > The OOM killer livelock was the motivation for this patch. With that > ruled out, what's the point of this patch? Try a bit less hard to move > charges during task migration? > Most important part is to fail ->can_attach() instead of oom killing

Re: [patch v2] mm, memcg: do not retry precharge charges

On Sat, 14 Jan 2017, Johannes Weiner wrote: > The OOM killer livelock was the motivation for this patch. With that > ruled out, what's the point of this patch? Try a bit less hard to move > charges during task migration? > Most important part is to fail ->can_attach() instead of oom killing

Re: [PATCH tip/core/rcu 0/9] Torture-test changes for 4.11

On Sat, Jan 14, 2017 at 01:13:36PM -0800, Josh Triplett wrote: > On Sat, Jan 14, 2017 at 01:25:33AM -0800, Paul E. McKenney wrote: > > Hello! > > > > This series provides torture-test updates: > > > > 1. Add a check for CONFIG_RCU_STALL_COMMON for TINY01, in order > > to complain if this

Re: [PATCH tip/core/rcu 0/9] Torture-test changes for 4.11

On Sat, Jan 14, 2017 at 01:13:36PM -0800, Josh Triplett wrote: > On Sat, Jan 14, 2017 at 01:25:33AM -0800, Paul E. McKenney wrote: > > Hello! > > > > This series provides torture-test updates: > > > > 1. Add a check for CONFIG_RCU_STALL_COMMON for TINY01, in order > > to complain if this

Re: [PATCH 07/22] openrisc: add atomic bitops

Hi Stefan, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc3 next-20170113] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 07/22] openrisc: add atomic bitops

Hi Stefan, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc3 next-20170113] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH tip/core/rcu 0/5] Documentation updates for 4.11

On Sat, Jan 14, 2017 at 12:45:08PM -0800, Josh Triplett wrote: > On Sat, Jan 14, 2017 at 12:50:32AM -0800, Paul E. McKenney wrote: > > Hello! > > > > This series provides documentation updates: > > > > 1. Add Design documentation for expedited grace periods. > > > > 2. Fix RCU requirements

Re: [PATCH tip/core/rcu 0/5] Documentation updates for 4.11

On Sat, Jan 14, 2017 at 12:45:08PM -0800, Josh Triplett wrote: > On Sat, Jan 14, 2017 at 12:50:32AM -0800, Paul E. McKenney wrote: > > Hello! > > > > This series provides documentation updates: > > > > 1. Add Design documentation for expedited grace periods. > > > > 2. Fix RCU requirements

Re: [PATCH] firmware: qcom: scm: add a video command for state setting

On Thu, Jan 12, 2017 at 07:15:05PM +0200, Stanimir Varbanov wrote: > This scm call is used to change the video core state, more > specifically it is used to suspend and resume the core. > > Signed-off-by: Stanimir Varbanov > --- It appears we have another patch

Re: [PATCH] firmware: qcom: scm: add a video command for state setting

On Thu, Jan 12, 2017 at 07:15:05PM +0200, Stanimir Varbanov wrote: > This scm call is used to change the video core state, more > specifically it is used to suspend and resume the core. > > Signed-off-by: Stanimir Varbanov > --- It appears we have another patch coming in that implements the

Re: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods

On Sat, Jan 14, 2017 at 11:35:25AM +0100, Borislav Petkov wrote: > On Sat, Jan 14, 2017 at 12:00:22AM -0800, Paul E. McKenney wrote: > > It now looks like this: > > > > > > > > Note that the code was buggy even before this

Re: [PATCH] rcu: Narrow early boot window of illegal synchronous grace periods

On Sat, Jan 14, 2017 at 11:35:25AM +0100, Borislav Petkov wrote: > On Sat, Jan 14, 2017 at 12:00:22AM -0800, Paul E. McKenney wrote: > > It now looks like this: > > > > > > > > Note that the code was buggy even before this

Re: [PATCH 00/22] Openrisc patchees from backlog for 4.11

On 01/14/2017 03:07 PM, Stafford Horne wrote: Hi All, This is another set of patches which I have been pulling out of the openrisc backlogs. Its a bit of a process since I need to cleanup commit messages, review and test the patches. The interesting things here are: - optimized memset and

Re: [PATCH 00/22] Openrisc patchees from backlog for 4.11

On 01/14/2017 03:07 PM, Stafford Horne wrote: Hi All, This is another set of patches which I have been pulling out of the openrisc backlogs. Its a bit of a process since I need to cleanup commit messages, review and test the patches. The interesting things here are: - optimized memset and

[PATCH] scsi: ibmvscsi: constify dev_pm_ops structures

Declare dev_pm_ops structures as const as they are only stored in the pm field of a vio_driver structure. This field is of type const, so dev_pm_ops structures having similar properties can be declared const. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i; position p; @@

[PATCH] scsi: ibmvscsi: constify dev_pm_ops structures

Declare dev_pm_ops structures as const as they are only stored in the pm field of a vio_driver structure. This field is of type const, so dev_pm_ops structures having similar properties can be declared const. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i; position p; @@

Calling device_init_wakeup() on driver removal

Hi folks, while looking through driver initialization and removal functions, I noticed that many drivers call device_init_wakeup(dev, false) in the removal function. Given that the driver is about to be removed, that doesn't make much sense to me, especially since device_wakeup_disable() is

Calling device_init_wakeup() on driver removal

Hi folks, while looking through driver initialization and removal functions, I noticed that many drivers call device_init_wakeup(dev, false) in the removal function. Given that the driver is about to be removed, that doesn't make much sense to me, especially since device_wakeup_disable() is

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

On Sun, 15 Jan 2017, Michael Schmitz wrote: > Am 15.01.2017 um 12:47 schrieb Finn Thain: > > > For the sake of discussion, I'll assume that the FDC driver will not > > be using DMA. (Perhaps FDC and SCSI can share the ST-DMA chip, using > > the present locking mechanism, but it would not

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

On Sun, 15 Jan 2017, Michael Schmitz wrote: > Am 15.01.2017 um 12:47 schrieb Finn Thain: > > > For the sake of discussion, I'll assume that the FDC driver will not > > be using DMA. (Perhaps FDC and SCSI can share the ST-DMA chip, using > > the present locking mechanism, but it would not

Re: [PATCH V2 6/6] gpio: davinci: Remove redundant macros

-Redesign-driver-to-accommodate-ngpios-in-one-gpio-chip/20170114-204048 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next config: arm-davinci_all_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget

Re: [PATCH V2 6/6] gpio: davinci: Remove redundant macros

-Redesign-driver-to-accommodate-ngpios-in-one-gpio-chip/20170114-204048 base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next config: arm-davinci_all_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget

[PATCH] iio: health: afe4404: retrieve a valid iio_dev in suspend/resume

The suspend/resume functions were using dev_to_iio_dev() to get the iio_dev. That only works on IIO dev's. Replace it with i2c functions to get the correct iio_dev. Signed-off-by: Alison Schofield --- drivers/iio/health/afe4404.c | 4 ++-- 1 file changed, 2 insertions(+),

[PATCH] iio: health: afe4403: retrieve a valid iio_dev in suspend/resume

The suspend/resume functions were using dev_to_iio_dev() to get the iio_dev. That only works on IIO dev's. Replace it with spi functions to get the correct iio_dev. Signed-off-by: Alison Schofield --- drivers/iio/health/afe4403.c | 4 ++-- 1 file changed, 2 insertions(+),

[PATCH] iio: health: afe4404: retrieve a valid iio_dev in suspend/resume

The suspend/resume functions were using dev_to_iio_dev() to get the iio_dev. That only works on IIO dev's. Replace it with i2c functions to get the correct iio_dev. Signed-off-by: Alison Schofield --- drivers/iio/health/afe4404.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH] iio: health: afe4403: retrieve a valid iio_dev in suspend/resume

The suspend/resume functions were using dev_to_iio_dev() to get the iio_dev. That only works on IIO dev's. Replace it with spi functions to get the correct iio_dev. Signed-off-by: Alison Schofield --- drivers/iio/health/afe4403.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[PATCH V6 10/18] blk-throttle: detect completed idle cgroup

cgroup could be assigned a limit, but doesn't dispatch enough IO, eg the cgroup is idle. When this happens, the cgroup doesn't hit its limit, so we can't move the state machine to higher level and all cgroups will be throttled to their lower limit, so we waste bandwidth. Detecting idle cgroup is

[PATCH V6 10/18] blk-throttle: detect completed idle cgroup

cgroup could be assigned a limit, but doesn't dispatch enough IO, eg the cgroup is idle. When this happens, the cgroup doesn't hit its limit, so we can't move the state machine to higher level and all cgroups will be throttled to their lower limit, so we waste bandwidth. Detecting idle cgroup is

[PATCH V6 07/18] blk-throttle: make sure expire time isn't too big

cgroup could be throttled to a limit but when all cgroups cross high limit, queue enters a higher state and so the group should be throttled to a higher limit. It's possible the cgroup is sleeping because of throttle and other cgroups don't dispatch IO any more. In this case, nobody can trigger

[PATCH V6 07/18] blk-throttle: make sure expire time isn't too big

cgroup could be throttled to a limit but when all cgroups cross high limit, queue enters a higher state and so the group should be throttled to a higher limit. It's possible the cgroup is sleeping because of throttle and other cgroups don't dispatch IO any more. In this case, nobody can trigger

[PATCH V6 17/18] blk-throttle: add a mechanism to estimate IO latency

User configures latency target, but the latency threshold for each request size isn't fixed. For a SSD, the IO latency highly depends on request size. To calculate latency threshold, we sample some data, eg, average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency threshold of each

[PATCH V6 17/18] blk-throttle: add a mechanism to estimate IO latency

User configures latency target, but the latency threshold for each request size isn't fixed. For a SSD, the IO latency highly depends on request size. To calculate latency threshold, we sample some data, eg, average latency for request size 4k, 8k, 16k, 32k .. 1M. The latency threshold of each

[PATCH V6 11/18] blk-throttle: make bandwidth change smooth

When cgroups all reach low limit, cgroups can dispatch more IO. This could make some cgroups dispatch more IO but others not, and even some cgroups could dispatch less IO than their low limit. For example, cg1 low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is 120M/s for the

[PATCH V6 11/18] blk-throttle: make bandwidth change smooth

When cgroups all reach low limit, cgroups can dispatch more IO. This could make some cgroups dispatch more IO but others not, and even some cgroups could dispatch less IO than their low limit. For example, cg1 low limit 10MB/s, cg2 limit 80MB/s, assume disk maximum bandwidth is 120M/s for the

[PATCH V6 16/18] block: track request size in blk_issue_stat

Currently there is no way to know the request size when the request is finished. Next patch will need this info. We could add extra field to record the size, but blk_issue_stat has enough space to record it, so this patch just overloads blk_issue_stat. With this, we will have 49bits to track time,

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > If a process invokes synchronize_srcu(), is delayed just the right amount > > of time, and thus does not sleep when waiting for the grace period to > > complete, there is

[PATCH V6 16/18] block: track request size in blk_issue_stat

Currently there is no way to know the request size when the request is finished. Next patch will need this info. We could add extra field to record the size, but blk_issue_stat has enough space to record it, so this patch just overloads blk_issue_stat. With this, we will have 49bits to track time,

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > If a process invokes synchronize_srcu(), is delayed just the right amount > > of time, and thus does not sleep when waiting for the grace period to > > complete, there is no ordering between the end

[PATCH V6 01/18] blk-throttle: use U64_MAX/UINT_MAX to replace -1

clean up the code to avoid using -1 Signed-off-by: Shaohua Li --- block/blk-throttle.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index a6bb4fe..e45bf50 100644 ---

[PATCH V6 01/18] blk-throttle: use U64_MAX/UINT_MAX to replace -1

clean up the code to avoid using -1 Signed-off-by: Shaohua Li --- block/blk-throttle.c | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index a6bb4fe..e45bf50 100644 --- a/block/blk-throttle.c +++

[PATCH V6 08/18] blk-throttle: make throtl_slice tunable

throtl_slice is important for blk-throttling. It's called slice internally but it really is a time window blk-throttling samples data. blk-throttling will make decision based on the samplings. An example is bandwidth measurement. A cgroup's bandwidth is measured in the time interval of

Re: [PATCH tip/core/rcu 1/3] srcu: More efficient reader counts.

On Sat, Jan 14, 2017 at 10:31:15AM +0100, Ingo Molnar wrote: > > Noticed a few minor nits: And thank you for the review and comments! > * Paul E. McKenney wrote: > > > From: Lance Roy > > > > SRCU uses two per-cpu counters: a nesting counter to

[PATCH V6 08/18] blk-throttle: make throtl_slice tunable

throtl_slice is important for blk-throttling. It's called slice internally but it really is a time window blk-throttling samples data. blk-throttling will make decision based on the samplings. An example is bandwidth measurement. A cgroup's bandwidth is measured in the time interval of

Re: [PATCH tip/core/rcu 1/3] srcu: More efficient reader counts.

On Sat, Jan 14, 2017 at 10:31:15AM +0100, Ingo Molnar wrote: > > Noticed a few minor nits: And thank you for the review and comments! > * Paul E. McKenney wrote: > > > From: Lance Roy > > > > SRCU uses two per-cpu counters: a nesting counter to count the number of > > active critical

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

On Sat, Jan 14, 2017 at 11:54:17AM -0800, Paul E. McKenney wrote: > On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney wrote: [ . . . ] > > > + */ > > > +#ifdef CONFIG_PPC > > > +#define smp_mb__after_unlock_lock() smp_mb() /*

[PATCH V6 13/18] blk-throttle: add interface to configure idle time threshold

Add interface to configure the threshold. The io.low interface will like: echo "8:16 rbps=2097152 wbps=max idle=2000" > io.low idle is in microsecond unit. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 41 - 1 file changed, 28

Re: [PATCH tip/core/rcu 2/3] srcu: Force full grace-period ordering

On Sat, Jan 14, 2017 at 11:54:17AM -0800, Paul E. McKenney wrote: > On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote: > > * Paul E. McKenney wrote: [ . . . ] > > > + */ > > > +#ifdef CONFIG_PPC > > > +#define smp_mb__after_unlock_lock() smp_mb() /* Full ordering for > > >

[PATCH V6 13/18] blk-throttle: add interface to configure idle time threshold

Add interface to configure the threshold. The io.low interface will like: echo "8:16 rbps=2097152 wbps=max idle=2000" > io.low idle is in microsecond unit. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 41 - 1 file changed, 28 insertions(+), 13

[PATCH V6 06/18] blk-throttle: add downgrade logic

When queue state machine is in LIMIT_MAX state, but a cgroup is below its low limit for some time, the queue should be downgraded to lower state as one cgroup's low limit isn't met. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 156

[PATCH V6 06/18] blk-throttle: add downgrade logic

When queue state machine is in LIMIT_MAX state, but a cgroup is below its low limit for some time, the queue should be downgraded to lower state as one cgroup's low limit isn't met. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 156 +++ 1

[PATCH V6 15/18] blk-throttle: add interface for per-cgroup target latency

Here we introduce per-cgroup latency target. The target determines how a cgroup can afford latency increasement. We will use the target latency to calculate a threshold and use it to schedule IO for cgroups. If a cgroup's bandwidth is below its low limit but its average latency is below the

[PATCH V6 15/18] blk-throttle: add interface for per-cgroup target latency

Here we introduce per-cgroup latency target. The target determines how a cgroup can afford latency increasement. We will use the target latency to calculate a threshold and use it to schedule IO for cgroups. If a cgroup's bandwidth is below its low limit but its average latency is below the

[PATCH V6 05/18] blk-throttle: add upgrade logic for LIMIT_LOW state

When queue is in LIMIT_LOW state and all cgroups with low limit cross the bps/iops limitation, we will upgrade queue's state to LIMIT_MAX. To determine if a cgroup exceeds its limitation, we check if the cgroup has pending request. Since cgroup is throttled according to the limit, pending request

[PATCH V6 05/18] blk-throttle: add upgrade logic for LIMIT_LOW state

When queue is in LIMIT_LOW state and all cgroups with low limit cross the bps/iops limitation, we will upgrade queue's state to LIMIT_MAX. To determine if a cgroup exceeds its limitation, we check if the cgroup has pending request. Since cgroup is throttled according to the limit, pending request

[PATCH V6 02/18] blk-throttle: prepare support multiple limits

We are going to support low/max limit, each cgroup will have 2 limits after that. This patch prepares for the multiple limits change. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 110 --- 1 file changed, 70 insertions(+), 40

[PATCH V6 02/18] blk-throttle: prepare support multiple limits

We are going to support low/max limit, each cgroup will have 2 limits after that. This patch prepares for the multiple limits change. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 110 --- 1 file changed, 70 insertions(+), 40 deletions(-)

[PATCH V6 09/18] blk-throttle: choose a small throtl_slice for SSD

The throtl_slice is 100ms by default. This is a long time for SSD, a lot of IO can run. To make cgroups have smoother throughput, we choose a small value (20ms) for SSD. Signed-off-by: Shaohua Li --- block/blk-sysfs.c| 2 ++ block/blk-throttle.c | 18 +++---

[PATCH V6 12/18] blk-throttle: add a simple idle detection

A cgroup gets assigned a low limit, but the cgroup could never dispatch enough IO to cross the low limit. In such case, the queue state machine will remain in LIMIT_LOW state and all other cgroups will be throttled according to low limit. This is unfair for other cgroups. We should treat the

[PATCH V6 09/18] blk-throttle: choose a small throtl_slice for SSD

The throtl_slice is 100ms by default. This is a long time for SSD, a lot of IO can run. To make cgroups have smoother throughput, we choose a small value (20ms) for SSD. Signed-off-by: Shaohua Li --- block/blk-sysfs.c| 2 ++ block/blk-throttle.c | 18 +++--- block/blk.h

[PATCH V6 12/18] blk-throttle: add a simple idle detection

A cgroup gets assigned a low limit, but the cgroup could never dispatch enough IO to cross the low limit. In such case, the queue state machine will remain in LIMIT_LOW state and all other cgroups will be throttled according to low limit. This is unfair for other cgroups. We should treat the

[PATCH V6 14/18] blk-throttle: ignore idle cgroup limit

Last patch introduces a way to detect idle cgroup. We use it to make upgrade/downgrade decision. And the new algorithm can detect completely idle cgroup too, so we can delete the corresponding code. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 40

[PATCH V6 18/18] blk-throttle: add latency target support

One hard problem adding .low limit is to detect idle cgroup. If one cgroup doesn't dispatch enough IO against its low limit, we must have a mechanism to determine if other cgroups dispatch more IO. We added the think time detection mechanism before, but it doesn't work for all workloads. Here we

[PATCH V6 14/18] blk-throttle: ignore idle cgroup limit

Last patch introduces a way to detect idle cgroup. We use it to make upgrade/downgrade decision. And the new algorithm can detect completely idle cgroup too, so we can delete the corresponding code. Signed-off-by: Shaohua Li --- block/blk-throttle.c | 40 ++--

[PATCH V6 18/18] blk-throttle: add latency target support

One hard problem adding .low limit is to detect idle cgroup. If one cgroup doesn't dispatch enough IO against its low limit, we must have a mechanism to determine if other cgroups dispatch more IO. We added the think time detection mechanism before, but it doesn't work for all workloads. Here we

[PATCH V6 04/18] blk-throttle: configure bps/iops limit for cgroup in low limit

each queue will have a state machine. Initially queue is in LIMIT_LOW state, which means all cgroups will be throttled according to their low limit. After all cgroups with low limit cross the limit, the queue state gets upgraded to LIMIT_MAX state. For max limit, cgroup will use the limit

[PATCH V6 04/18] blk-throttle: configure bps/iops limit for cgroup in low limit

each queue will have a state machine. Initially queue is in LIMIT_LOW state, which means all cgroups will be throttled according to their low limit. After all cgroups with low limit cross the limit, the queue state gets upgraded to LIMIT_MAX state. For max limit, cgroup will use the limit

[PATCH V6 03/18] blk-throttle: add .low interface

Add low limit for cgroup and corresponding cgroup interface. To be consistent with memcg, we allow users configure .low limit higher than .max limit. But the internal logic always assumes .low limit is lower than .max limit. So we add extra bps/iops_conf fields in throtl_grp for userspace

[PATCH V6 03/18] blk-throttle: add .low interface

Add low limit for cgroup and corresponding cgroup interface. To be consistent with memcg, we allow users configure .low limit higher than .max limit. But the internal logic always assumes .low limit is lower than .max limit. So we add extra bps/iops_conf fields in throtl_grp for userspace

[PATCH V6 00/18] blk-throttle: add .low limit

Hi, cgroup still lacks a good iocontroller. CFQ works well for hard disk, but not much for SSD. This patch set try to add a conservative limit for blk-throttle. It isn't a proportional scheduling, but can help prioritize cgroups. There are several advantages we choose blk-throttle: - blk-throttle

[PATCH V6 00/18] blk-throttle: add .low limit

Hi, cgroup still lacks a good iocontroller. CFQ works well for hard disk, but not much for SSD. This patch set try to add a conservative limit for blk-throttle. It isn't a proportional scheduling, but can help prioritize cgroups. There are several advantages we choose blk-throttle: - blk-throttle

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

On 01/15/2017 12:54 AM, Eduardo Valentin wrote: Folks, On Wed, Jan 04, 2017 at 12:30:40AM +0800, ayaka wrote: On 01/03/2017 09:13 AM, Randy Li wrote: On 01/03/2017 09:02 AM, Caesar Wang wrote: 在 2017年01月03日 07:57, Randy Li 写道: On 01/02/2017 09:16 PM, Caesar Wang wrote: 在 2016年12月31日

Re: [PATCH v4 0/5] thermal: fixes the rockchip thermal

On 01/15/2017 12:54 AM, Eduardo Valentin wrote: Folks, On Wed, Jan 04, 2017 at 12:30:40AM +0800, ayaka wrote: On 01/03/2017 09:13 AM, Randy Li wrote: On 01/03/2017 09:02 AM, Caesar Wang wrote: 在 2017年01月03日 07:57, Randy Li 写道: On 01/02/2017 09:16 PM, Caesar Wang wrote: 在 2016年12月31日

Re: [PATCH v6 0/4] ARM: Add support for CONFIG_DEBUG_VIRTUAL

Le 01/04/17 à 14:39, Florian Fainelli a écrit : > This patch series builds on top of Laura's [PATCHv6 00/10] > CONFIG_DEBUG_VIRTUAL > for arm64 to add support for CONFIG_DEBUG_VIRTUAL for ARM. > > This was tested on a Brahma B15 platform (ARMv7 + HIGHMEM + LPAE). > > Note that the treewide

Re: [PATCH v6 0/4] ARM: Add support for CONFIG_DEBUG_VIRTUAL

Le 01/04/17 à 14:39, Florian Fainelli a écrit : > This patch series builds on top of Laura's [PATCHv6 00/10] > CONFIG_DEBUG_VIRTUAL > for arm64 to add support for CONFIG_DEBUG_VIRTUAL for ARM. > > This was tested on a Brahma B15 platform (ARMv7 + HIGHMEM + LPAE). > > Note that the treewide

cc1: error: '-march=r3900' requires '-mfp32'

Hi James, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f0ad17712b9f71c24e2b8b9725230ef57232377f commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of vdso.lds date: 3 months ago config:

cc1: error: '-march=r3900' requires '-mfp32'

Hi James, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f0ad17712b9f71c24e2b8b9725230ef57232377f commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of vdso.lds date: 3 months ago config:

Re: [PATCH v7 1/7] perf/amd/iommu: Misc fix up perf_iommu_read

Peter, On 1/11/17 18:57, Peter Zijlstra wrote: On Mon, Jan 09, 2017 at 09:33:41PM -0600, Suravee Suthikulpanit wrote: This patch contains the following minor fixup: * Fixed overflow handling since u64 delta would lose the MSB sign bit. Please explain.. afaict this actually introduces a

Re: [PATCH v7 1/7] perf/amd/iommu: Misc fix up perf_iommu_read

Peter, On 1/11/17 18:57, Peter Zijlstra wrote: On Mon, Jan 09, 2017 at 09:33:41PM -0600, Suravee Suthikulpanit wrote: This patch contains the following minor fixup: * Fixed overflow handling since u64 delta would lose the MSB sign bit. Please explain.. afaict this actually introduces a

  1   2   3   4   5   6   7   >