Re: [PATCH 3/4] mm, page_alloc: fix dirtyable highmem calculation

On 07/13/2016 12:00 PM, Mel Gorman wrote: From: Minchan Kim Note from Mel: This may optionally be considered a fix to the mmotm patch mm-page_alloc-consider-dirtyable-memory-in-terms-of-nodes.patch but if so, please preserve credit for Minchan. When I

[PATCH 1/7 v3] drm/vc4: Add a getparam ioctl for getting the V3D identity regs.

As I extend the driver to support different V3D revisions, userspace needs to know what version it's targeting. This is most easily detected using the V3D identity registers. v2: Make sure V3D is runtime PM on when reading the registers. v3: Switch to a 64-bit param value (suggested by Rob Clark

Re: [PATCH 3/4] mm, page_alloc: fix dirtyable highmem calculation

On 07/13/2016 12:00 PM, Mel Gorman wrote: From: Minchan Kim Note from Mel: This may optionally be considered a fix to the mmotm patch mm-page_alloc-consider-dirtyable-memory-in-terms-of-nodes.patch but if so, please preserve credit for Minchan. When I tested vmscale in mmtest

[PATCH 1/7 v3] drm/vc4: Add a getparam ioctl for getting the V3D identity regs.

As I extend the driver to support different V3D revisions, userspace needs to know what version it's targeting. This is most easily detected using the V3D identity registers. v2: Make sure V3D is runtime PM on when reading the registers. v3: Switch to a 64-bit param value (suggested by Rob Clark

[PATCH] drm/rockchip: allocate correct crtc state structure on reset

Because we are using a custom crtc_state structure, we must override the reset helper to allocate the correct amount of memory. Cc: sta...@vger.kernel.org Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config") Signed-off-by: John Keeping ---

[PATCH] drm/rockchip: allocate correct crtc state structure on reset

Because we are using a custom crtc_state structure, we must override the reset helper to allocate the correct amount of memory. Cc: sta...@vger.kernel.org Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config") Signed-off-by: John Keeping ---

Re: System freezes after OOM

On Wed 13-07-16 16:53:28, David Rientjes wrote: > On Wed, 13 Jul 2016, Mikulas Patocka wrote: > > > What are the real problems that f9054c70d28bc214b2857cf8db8269f4f45a5e23 > > tries to fix? > > > > It prevents the whole system from livelocking due to an oom killed process > stalling forever

Re: System freezes after OOM

On Wed 13-07-16 16:53:28, David Rientjes wrote: > On Wed, 13 Jul 2016, Mikulas Patocka wrote: > > > What are the real problems that f9054c70d28bc214b2857cf8db8269f4f45a5e23 > > tries to fix? > > > > It prevents the whole system from livelocking due to an oom killed process > stalling forever

Re: [PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

On Thu, Jul 14, 2016 at 12:15:58PM +0800, Yakir Yang wrote: > Alway enable the PSR function for Rockchip analogix_dp driver. If panel > don't support PSR, then the core analogix_dp would ignore this setting. > > Signed-off-by: Yakir Yang Reviewed-by: Sean Paul

Re: [PATCH v4 4/4] drm/rockchip: analogix_dp: implement PSR function

On Thu, Jul 14, 2016 at 12:15:58PM +0800, Yakir Yang wrote: > Alway enable the PSR function for Rockchip analogix_dp driver. If panel > don't support PSR, then the core analogix_dp would ignore this setting. > > Signed-off-by: Yakir Yang Reviewed-by: Sean Paul > --- > Changes in v4: > -

Re: Purpose of pci_remap_iospace

On Thu, Jul 14, 2016 at 05:12:01PM +0200, Arnd Bergmann wrote: > On Thursday, July 14, 2016 3:56:24 PM CEST Lorenzo Pieralisi wrote: > > On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > > > [...] > > > > > Hi Lorenzo, > > > > > > I missed something in my device tree now

Re: Purpose of pci_remap_iospace

On Thu, Jul 14, 2016 at 05:12:01PM +0200, Arnd Bergmann wrote: > On Thursday, July 14, 2016 3:56:24 PM CEST Lorenzo Pieralisi wrote: > > On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > > > [...] > > > > > Hi Lorenzo, > > > > > > I missed something in my device tree now

Re: System freezes after OOM

On 07/14/2016 04:59 PM, Michal Hocko wrote: On Thu 14-07-16 10:00:16, Mikulas Patocka wrote: On Thu, 14 Jul 2016, Michal Hocko wrote: On Wed 13-07-16 11:02:15, Mikulas Patocka wrote: diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 4f3cb3554944..0b806810efab 100644 ---

Re: System freezes after OOM

On 07/14/2016 04:59 PM, Michal Hocko wrote: On Thu 14-07-16 10:00:16, Mikulas Patocka wrote: On Thu, 14 Jul 2016, Michal Hocko wrote: On Wed 13-07-16 11:02:15, Mikulas Patocka wrote: diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 4f3cb3554944..0b806810efab 100644 ---

Re: System freezes after OOM

On 07/14/2016 02:51 PM, Michal Hocko wrote: On Wed 13-07-16 11:02:15, Mikulas Patocka wrote: On Wed, 13 Jul 2016, Michal Hocko wrote: [...] We are discussing several topics together so let's focus on this particlar thing for now The kernel 4.7-rc almost deadlocks in another way. The machine

[PATCH net-next] rxrpc: checking for IS_ERR() instead of NULL

From: Dan Carpenter The rxrpc_lookup_peer() function returns NULL on error, it never returns error pointers. Fixes: 8496af50eb38 ('rxrpc: Use RCU to access a peer's service connection tree') Signed-off-by: Dan Carpenter Signed-off-by: David

[PATCH v4 1/2] arch, x86, tsc deadline clockevent dev: eliminate frequency roundoff error

In setup_APIC_timer(), the registered clockevent device's frequency is calculated by first dividing tsc_khz by TSC_DIVISOR and multiplying it with 1000 afterwards: (tsc_khz / TSC_DIVISOR) * 1000 The multiplication with 1000 is done for converting from kHz to Hz and the division by TSC_DIVISOR

[PATCH v4 2/2] arch, x86, tsc: inform TSC deadline clockevent device about recalibration

The TSC deadline clockevent devices' configuration and registration happens before the TSC frequency calibration is refined in tsc_refine_calibration_work(). This results in the TSC clocksource and the TSC deadline clockevent devices being configured with slightly different frequencies: the

Re: [PATCH v4 3/4] drm/bridge: analogix_dp: add the PSR function support

On Thu, Jul 14, 2016 at 12:15:53PM +0800, Yakir Yang wrote: > The full name of PSR is Panel Self Refresh, panel device could refresh > itself with the hardware framebuffer in panel, this would make lots of > sense to save the power consumption. > > This patch have exported two symbols for

[PATCH v4 0/2] reduce TSC deadline frequency errors

The v3 series can be found at http://lkml.kernel.org/g/20160713130344.8319-1-nicsta...@gmail.com Applicable to linux-next-20160708 (in case you wonder why I turned back from the 20160712 given in v3 to 20160708 again: mysteriously, 20160712 doesn't boot neither w/ nor w/o this series anymore).

Re: System freezes after OOM

On 07/14/2016 02:51 PM, Michal Hocko wrote: On Wed 13-07-16 11:02:15, Mikulas Patocka wrote: On Wed, 13 Jul 2016, Michal Hocko wrote: [...] We are discussing several topics together so let's focus on this particlar thing for now The kernel 4.7-rc almost deadlocks in another way. The machine

[PATCH net-next] rxrpc: checking for IS_ERR() instead of NULL

From: Dan Carpenter The rxrpc_lookup_peer() function returns NULL on error, it never returns error pointers. Fixes: 8496af50eb38 ('rxrpc: Use RCU to access a peer's service connection tree') Signed-off-by: Dan Carpenter Signed-off-by: David Howells --- net/rxrpc/conn_service.c |2 +- 1

[PATCH v4 1/2] arch, x86, tsc deadline clockevent dev: eliminate frequency roundoff error

In setup_APIC_timer(), the registered clockevent device's frequency is calculated by first dividing tsc_khz by TSC_DIVISOR and multiplying it with 1000 afterwards: (tsc_khz / TSC_DIVISOR) * 1000 The multiplication with 1000 is done for converting from kHz to Hz and the division by TSC_DIVISOR

[PATCH v4 2/2] arch, x86, tsc: inform TSC deadline clockevent device about recalibration

The TSC deadline clockevent devices' configuration and registration happens before the TSC frequency calibration is refined in tsc_refine_calibration_work(). This results in the TSC clocksource and the TSC deadline clockevent devices being configured with slightly different frequencies: the

Re: [PATCH v4 3/4] drm/bridge: analogix_dp: add the PSR function support

On Thu, Jul 14, 2016 at 12:15:53PM +0800, Yakir Yang wrote: > The full name of PSR is Panel Self Refresh, panel device could refresh > itself with the hardware framebuffer in panel, this would make lots of > sense to save the power consumption. > > This patch have exported two symbols for

[PATCH v4 0/2] reduce TSC deadline frequency errors

The v3 series can be found at http://lkml.kernel.org/g/20160713130344.8319-1-nicsta...@gmail.com Applicable to linux-next-20160708 (in case you wonder why I turned back from the 20160712 given in v3 to 20160708 again: mysteriously, 20160712 doesn't boot neither w/ nor w/o this series anymore).

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On Thu, Jul 14, 2016 at 11:07:15AM -0400, Tejun Heo wrote: > On Thu, Jul 14, 2016 at 02:20:49PM +0200, Peter Zijlstra wrote: > > > If that's the case, we have the wrong implemention > > > for percpu-rwsem where very long delays for writers induce the same > > > level of delays to all readers. If

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On Thu, Jul 14, 2016 at 11:07:15AM -0400, Tejun Heo wrote: > On Thu, Jul 14, 2016 at 02:20:49PM +0200, Peter Zijlstra wrote: > > > If that's the case, we have the wrong implemention > > > for percpu-rwsem where very long delays for writers induce the same > > > level of delays to all readers. If

Re: Purpose of pci_remap_iospace

On Thu, Jul 14, 2016 at 03:05:40PM +, Bharat Kumar Gogada wrote: [...] > > On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > > ranges = <0x0100 0x 0xe000 0x 0xe000 0 > > 0x0001 //io > > > > You have not missed anything, you changed the

Re: [PATCH 0/8] x86: audit and remove needless module.h includes

[Re: [PATCH 0/8] x86: audit and remove needless module.h includes] On 14/07/2016 (Thu 15:04) Ingo Molnar wrote: > > * Paul Gortmaker wrote: > > > To that end, I have done allmodconfig, allyesconfig and allnoconfig > > for both 32 bit and 64 bit x86 with these

Re: Purpose of pci_remap_iospace

On Thu, Jul 14, 2016 at 03:05:40PM +, Bharat Kumar Gogada wrote: [...] > > On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > > ranges = <0x0100 0x 0xe000 0x 0xe000 0 > > 0x0001 //io > > > > You have not missed anything, you changed the

Re: [PATCH 0/8] x86: audit and remove needless module.h includes

[Re: [PATCH 0/8] x86: audit and remove needless module.h includes] On 14/07/2016 (Thu 15:04) Ingo Molnar wrote: > > * Paul Gortmaker wrote: > > > To that end, I have done allmodconfig, allyesconfig and allnoconfig > > for both 32 bit and 64 bit x86 with these changes on the linux-next > >

Re: [PATCH] arm64: Add config to limit user space to 47bits

On 13 July 2016 at 18:14, Alexander Graf wrote: > On 07/13/2016 05:59 PM, Ard Biesheuvel wrote: >> >> On 13 July 2016 at 17:42, Alexander Graf wrote: >>> >>> Some user space applications are known to break with 48 bits virtual >> >> known by whom? At least I wasn't

Re: [PATCH] arm64: Add config to limit user space to 47bits

On 13 July 2016 at 18:14, Alexander Graf wrote: > On 07/13/2016 05:59 PM, Ard Biesheuvel wrote: >> >> On 13 July 2016 at 17:42, Alexander Graf wrote: >>> >>> Some user space applications are known to break with 48 bits virtual >> >> known by whom? At least I wasn't aware of it, so could you

[PATCH] [media] vb2: include length in dmabuf qbuf debug message

If the the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's useful to get the invalid length as a debug information. Before this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1 After this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1

[PATCH] [media] vb2: include length in dmabuf qbuf debug message

If the the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's useful to get the invalid length as a debug information. Before this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1 After this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1

Re: [PATCH v4 2/4] drm/rockchip: add an common abstracted PSR driver

On Thu, Jul 14, 2016 at 12:15:49PM +0800, Yakir Yang wrote: > The PSR driver have exported four symbols for specific device driver: > - rockchip_drm_psr_register() > - rockchip_drm_psr_unregister() > - rockchip_drm_psr_enable() > - rockchip_drm_psr_disable() > - rockchip_drm_psr_flush() > >

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On Thu, Jul 14, 2016 at 02:11:01PM +0200, Peter Zijlstra wrote: > > How so? As the number of cores increases, it'll get proportionally > > more expensive as the same operation is performed on more CPUs; > > however, the latency is dependent on the slowest one and it'll get > > higher more often

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On Thu, Jul 14, 2016 at 02:11:01PM +0200, Peter Zijlstra wrote: > > How so? As the number of cores increases, it'll get proportionally > > more expensive as the same operation is performed on more CPUs; > > however, the latency is dependent on the slowest one and it'll get > > higher more often

Re: [PATCH v4 2/4] drm/rockchip: add an common abstracted PSR driver

On Thu, Jul 14, 2016 at 12:15:49PM +0800, Yakir Yang wrote: > The PSR driver have exported four symbols for specific device driver: > - rockchip_drm_psr_register() > - rockchip_drm_psr_unregister() > - rockchip_drm_psr_enable() > - rockchip_drm_psr_disable() > - rockchip_drm_psr_flush() > >

Re: [PATCH v2 06/13] sched: Store maximum per-cpu capacity in root domain

On Thu, Jul 14, 2016 at 03:25:36PM +0200, Vincent Guittot wrote: > On 13 July 2016 at 18:37, Morten Rasmussen wrote: > > On Wed, Jul 13, 2016 at 02:48:24PM +0100, Dietmar Eggemann wrote: > >> On 13/07/16 13:40, Vincent Guittot wrote: > >> > On 22 June 2016 at 19:03,

Re: [PATCH v2 06/13] sched: Store maximum per-cpu capacity in root domain

On Thu, Jul 14, 2016 at 03:25:36PM +0200, Vincent Guittot wrote: > On 13 July 2016 at 18:37, Morten Rasmussen wrote: > > On Wed, Jul 13, 2016 at 02:48:24PM +0100, Dietmar Eggemann wrote: > >> On 13/07/16 13:40, Vincent Guittot wrote: > >> > On 22 June 2016 at 19:03, Morten Rasmussen > >> >

Re: Purpose of pci_remap_iospace

On Thursday, July 14, 2016 3:56:24 PM CEST Lorenzo Pieralisi wrote: > On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > [...] > > > Hi Lorenzo, > > > > I missed something in my device tree now I corrected it. > > > > ranges = <0x0100 0x 0xe000 0x

Re: Purpose of pci_remap_iospace

On Thursday, July 14, 2016 3:56:24 PM CEST Lorenzo Pieralisi wrote: > On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > [...] > > > Hi Lorenzo, > > > > I missed something in my device tree now I corrected it. > > > > ranges = <0x0100 0x 0xe000 0x

RE: [PATCH v3 5/8] thunderbolt: Communication with the ICM (firmware)

Hi Amir, Here are my 2 cents: This method always returns true, should be void (unless you will change PDF_ERROR_NOTIFICATION or other pdf values to return false), and likewise its invocation should not check return value. > +static bool nhi_msg_from_icm_analysis(struct tbt_nhi_ctxt

RE: [PATCH v3 5/8] thunderbolt: Communication with the ICM (firmware)

Hi Amir, Here are my 2 cents: This method always returns true, should be void (unless you will change PDF_ERROR_NOTIFICATION or other pdf values to return false), and likewise its invocation should not check return value. > +static bool nhi_msg_from_icm_analysis(struct tbt_nhi_ctxt

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On Thu, Jul 14, 2016 at 02:20:49PM +0200, Peter Zijlstra wrote: > > If that's the case, we have the wrong implemention > > for percpu-rwsem where very long delays for writers induce the same > > level of delays to all readers. If expedited by default isn't > > workable, we should move away from

Re: [PATCH v2] media: s5p-mfc remove unnecessary error messages

Hello Shuah, On 07/14/2016 10:40 AM, Shuah Khan wrote: > Removed unnecessary error message as appropriate error code is returned. > Changed error message into a debug. > > Signed-off-by: Shuah Khan > --- Reviewed-by: Javier Martinez Canillas

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On Thu, Jul 14, 2016 at 02:20:49PM +0200, Peter Zijlstra wrote: > > If that's the case, we have the wrong implemention > > for percpu-rwsem where very long delays for writers induce the same > > level of delays to all readers. If expedited by default isn't > > workable, we should move away from

Re: [PATCH v2] media: s5p-mfc remove unnecessary error messages

Hello Shuah, On 07/14/2016 10:40 AM, Shuah Khan wrote: > Removed unnecessary error message as appropriate error code is returned. > Changed error message into a debug. > > Signed-off-by: Shuah Khan > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open

[PATCH] mmc: pxamci: fix potential oops

As reported by Dan in his report in [1], there is a potential NULL pointer derefence if these conditions are met : - there is no platform_data provided, ie. host->pdata = NULL Fix this by only using the platform data ro_invert when a gpio for read-only is provided by the platform data. This

[PATCH] mmc: pxamci: fix potential oops

As reported by Dan in his report in [1], there is a potential NULL pointer derefence if these conditions are met : - there is no platform_data provided, ie. host->pdata = NULL Fix this by only using the platform data ro_invert when a gpio for read-only is provided by the platform data. This

Re: [PATCH v2 1/7] lib/dlock-list: Distributed and lock-protected lists

Hello, Jan. On Thu, Jul 14, 2016 at 04:35:47PM +0200, Jan Kara wrote: > > > The current use case only need to use the regular lock functions. You are > > > right that future use cases may require an irqsafe version of locks. I can > > > either modify the code now to allow lock type selection at

Re: [PATCH v2 1/7] lib/dlock-list: Distributed and lock-protected lists

Hello, Jan. On Thu, Jul 14, 2016 at 04:35:47PM +0200, Jan Kara wrote: > > > The current use case only need to use the regular lock functions. You are > > > right that future use cases may require an irqsafe version of locks. I can > > > either modify the code now to allow lock type selection at

RE: Purpose of pci_remap_iospace

> On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > [...] > > > Hi Lorenzo, > > > > I missed something in my device tree now I corrected it. > > > > ranges = <0x0100 0x 0xe000 0x 0xe000 0 > 0x0001 //io > > You have not missed anything, you

RE: Purpose of pci_remap_iospace

> On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: > > [...] > > > Hi Lorenzo, > > > > I missed something in my device tree now I corrected it. > > > > ranges = <0x0100 0x 0xe000 0x 0xe000 0 > 0x0001 //io > > You have not missed anything, you

Re: [Query] Preemption (hogging) of the work handler

On Thu 14-07-16 23:34:50, Sergey Senozhatsky wrote: > Hello Jan, > > On (07/14/16 16:12), Jan Kara wrote: > [..] > > > *** a printk() call from here will kill the system. either it will > > > recurse printk(), or spin forever in 'nested' printk() on one of > > > the already taken spin locks. >

Re: [Query] Preemption (hogging) of the work handler

On Thu 14-07-16 23:34:50, Sergey Senozhatsky wrote: > Hello Jan, > > On (07/14/16 16:12), Jan Kara wrote: > [..] > > > *** a printk() call from here will kill the system. either it will > > > recurse printk(), or spin forever in 'nested' printk() on one of > > > the already taken spin locks. >

Re: [PATCH v2] locking/pvqspinlock: restore/set vcpu_hashed state after failing adaptive locking spinning

On 07/14/2016 07:26 AM, Peter Zijlstra wrote: On Thu, Jul 14, 2016 at 04:15:56PM +0800, Wanpeng Li wrote: In this case, lock holder inserts the pv_node of queue head into the hash table and set _Q_SLOW_VAL unnecessary. This patch avoids it by restoring/setting vcpu_halted state after failing

Re: [PATCH v2] locking/pvqspinlock: restore/set vcpu_hashed state after failing adaptive locking spinning

On 07/14/2016 07:26 AM, Peter Zijlstra wrote: On Thu, Jul 14, 2016 at 04:15:56PM +0800, Wanpeng Li wrote: In this case, lock holder inserts the pv_node of queue head into the hash table and set _Q_SLOW_VAL unnecessary. This patch avoids it by restoring/setting vcpu_halted state after failing

Re: System freezes after OOM

On Thu 14-07-16 10:00:16, Mikulas Patocka wrote: > > > On Thu, 14 Jul 2016, Michal Hocko wrote: > > > On Wed 13-07-16 11:02:15, Mikulas Patocka wrote: > > > > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > > > > index 4f3cb3554944..0b806810efab 100644 > > > > ---

[ANNOUNCE] 3.4.112-rt143

Dear RT Folks, I'm pleased to announce the 3.4.112-rt143 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.4-rt Head SHA1: 7a6baa46e0f5e19beea329413b9832722f86ee5e Or to build 3.4.112-rt143

Re: System freezes after OOM

On Thu 14-07-16 10:00:16, Mikulas Patocka wrote: > > > On Thu, 14 Jul 2016, Michal Hocko wrote: > > > On Wed 13-07-16 11:02:15, Mikulas Patocka wrote: > > > > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > > > > index 4f3cb3554944..0b806810efab 100644 > > > > ---

[ANNOUNCE] 3.4.112-rt143

Dear RT Folks, I'm pleased to announce the 3.4.112-rt143 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.4-rt Head SHA1: 7a6baa46e0f5e19beea329413b9832722f86ee5e Or to build 3.4.112-rt143

[ANNOUNCE] 3.2.81-rt117

Dear RT Folks, I'm pleased to announce the 3.2.81-rt117 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.2-rt Head SHA1: fe7588485c196d9dcfb35019c846c7f9cdde64fa Or to build 3.2.81-rt117

[ANNOUNCE] 3.2.81-rt117

Dear RT Folks, I'm pleased to announce the 3.2.81-rt117 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.2-rt Head SHA1: fe7588485c196d9dcfb35019c846c7f9cdde64fa Or to build 3.2.81-rt117

[ANNOUNCE] 3.14.72-rt76

Dear RT Folks, I'm pleased to announce the 3.14.72-rt76 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.14-rt Head SHA1: e9deb8e0208728e04f658d89e60e641f0beefe54 Or to build 3.14.72-rt76

[ANNOUNCE] 3.14.72-rt76

Dear RT Folks, I'm pleased to announce the 3.14.72-rt76 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.14-rt Head SHA1: e9deb8e0208728e04f658d89e60e641f0beefe54 Or to build 3.14.72-rt76

[ANNOUNCE] 3.12.61-rt82

Dear RT Folks, I'm pleased to announce the 3.12.61-rt82 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.12-rt Head SHA1: 275c808f91fc8e1873873718290a7f242fe127cd Or to build 3.12.61-rt82

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On 07/14, Peter Zijlstra wrote: > > OK, not too horrible if I say so myself :-) > > The below is a compile tested only first draft so far. I'll go give it > some runtime next. Yes, thanks. But note that we do not need RCU_NONE. All we need is the trivial change below. Damn, I am trying to find

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On 07/14, Peter Zijlstra wrote: > > OK, not too horrible if I say so myself :-) > > The below is a compile tested only first draft so far. I'll go give it > some runtime next. Yes, thanks. But note that we do not need RCU_NONE. All we need is the trivial change below. Damn, I am trying to find

[ANNOUNCE] 3.12.61-rt82

Dear RT Folks, I'm pleased to announce the 3.12.61-rt82 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.12-rt Head SHA1: 275c808f91fc8e1873873718290a7f242fe127cd Or to build 3.12.61-rt82

[ANNOUNCE] 3.10.102-rt113

Dear RT Folks, I'm pleased to announce the 3.10.102-rt113 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.10-rt Head SHA1: 1df43a742d5375abf819762126f484afe674dbda Or to build 3.10.102-rt113

[ANNOUNCE] 3.10.102-rt113

Dear RT Folks, I'm pleased to announce the 3.10.102-rt113 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.10-rt Head SHA1: 1df43a742d5375abf819762126f484afe674dbda Or to build 3.10.102-rt113

[ANNOUNCE] 3.18.36-rt38

Dear RT Folks, I'm pleased to announce the 3.18.36-rt38 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.18-rt Head SHA1: cf3a38958bb4b88e877e89b7e323d1f26cd35b46 Or to build 3.18.36-rt38

[ANNOUNCE] 3.18.36-rt38

Dear RT Folks, I'm pleased to announce the 3.18.36-rt38 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.18-rt Head SHA1: cf3a38958bb4b88e877e89b7e323d1f26cd35b46 Or to build 3.18.36-rt38

[ANNOUNCE] 4.1.27-rt31

Dear RT Folks, I'm pleased to announce the 4.1.27-rt31 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.1-rt Head SHA1: 19f31cf0a5e2c6c52d7b0ca781121d774a103041 Or to build 4.1.27-rt31

[ANNOUNCE] 4.1.27-rt31

Dear RT Folks, I'm pleased to announce the 4.1.27-rt31 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.1-rt Head SHA1: 19f31cf0a5e2c6c52d7b0ca781121d774a103041 Or to build 4.1.27-rt31

[ANNOUNCE] 4.4.12-rt20

Dear RT Folks, I'm pleased to announce the 4.4.12-rt20 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.4-rt Head SHA1: b4059f165a21ace3e150cf8e14752bb05f27137b Or to build 4.4.12-rt20

[ANNOUNCE] 4.4.12-rt20

Dear RT Folks, I'm pleased to announce the 4.4.12-rt20 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.4-rt Head SHA1: b4059f165a21ace3e150cf8e14752bb05f27137b Or to build 4.4.12-rt20

Re: [Query] Preemption (hogging) of the work handler

On Thu 14-07-16 16:47:11, Rafael J. Wysocki wrote: > On Thursday, July 14, 2016 04:39:39 PM Jan Kara wrote: > > On Thu 14-07-16 16:33:38, Rafael J. Wysocki wrote: > > > On Thursday, July 14, 2016 04:12:16 PM Jan Kara wrote: > > > > On Wed 13-07-16 14:45:07, Sergey Senozhatsky wrote: > > > > > Cc

Re: [Query] Preemption (hogging) of the work handler

On Thu 14-07-16 16:47:11, Rafael J. Wysocki wrote: > On Thursday, July 14, 2016 04:39:39 PM Jan Kara wrote: > > On Thu 14-07-16 16:33:38, Rafael J. Wysocki wrote: > > > On Thursday, July 14, 2016 04:12:16 PM Jan Kara wrote: > > > > On Wed 13-07-16 14:45:07, Sergey Senozhatsky wrote: > > > > > Cc

Re: Purpose of pci_remap_iospace

On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: [...] > Hi Lorenzo, > > I missed something in my device tree now I corrected it. > > ranges = <0x0100 0x 0xe000 0x 0xe000 0 0x0001 > //io You have not missed anything, you changed the PCI

Re: Purpose of pci_remap_iospace

On Thu, Jul 14, 2016 at 01:32:13PM +, Bharat Kumar Gogada wrote: [...] > Hi Lorenzo, > > I missed something in my device tree now I corrected it. > > ranges = <0x0100 0x 0xe000 0x 0xe000 0 0x0001 > //io You have not missed anything, you changed the PCI

Re: [PATCH v3] locking/pvqspinlock: restore/set vcpu_hashed state after failing adaptive locking spinning

On 07/14/2016 07:39 AM, Wanpeng Li wrote: From: Wanpeng Li When the lock holder vCPU is racing with the queue head: CPU 0 (lock holder)CPU 1 (queue head) ==== spin_lock(); spin_lock(); pv_kick_node():

Re: [PATCH v3] locking/pvqspinlock: restore/set vcpu_hashed state after failing adaptive locking spinning

On 07/14/2016 07:39 AM, Wanpeng Li wrote: From: Wanpeng Li When the lock holder vCPU is racing with the queue head: CPU 0 (lock holder)CPU 1 (queue head) ==== spin_lock(); spin_lock(); pv_kick_node():

RE: [PATCH v3 5/8] thunderbolt: Communication with the ICM (firmware)

Hi Tomas, Thanks for your comments. On Thu, Jul 14 2016, 03:44 PM, Winkler, Tomas wrote: > > +/* NHI genetlink commands */ > > +enum { > > + NHI_CMD_UNSPEC, > > + NHI_CMD_SUBSCRIBE, > > + NHI_CMD_UNSUBSCRIBE, > > + NHI_CMD_QUERY_INFORMATION, > > + NHI_CMD_MSG_TO_ICM, > > +

Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

On 14/07/16 15:24, Dave Hansen wrote: > On 07/14/2016 06:47 AM, Vlastimil Babka wrote: >> So, this might be just because I know next to nothing about (para)virt, >> but... >> >> in arch/x86/include/asm/paravirt.h, pte_val is implemented via some >> pvops, which suggests that obtaining a pte value

RE: [PATCH v3 5/8] thunderbolt: Communication with the ICM (firmware)

Hi Tomas, Thanks for your comments. On Thu, Jul 14 2016, 03:44 PM, Winkler, Tomas wrote: > > +/* NHI genetlink commands */ > > +enum { > > + NHI_CMD_UNSPEC, > > + NHI_CMD_SUBSCRIBE, > > + NHI_CMD_UNSUBSCRIBE, > > + NHI_CMD_QUERY_INFORMATION, > > + NHI_CMD_MSG_TO_ICM, > > +

Re: [PATCH 4/4] x86: use pte_none() to test for empty PTE

On 14/07/16 15:24, Dave Hansen wrote: > On 07/14/2016 06:47 AM, Vlastimil Babka wrote: >> So, this might be just because I know next to nothing about (para)virt, >> but... >> >> in arch/x86/include/asm/paravirt.h, pte_val is implemented via some >> pvops, which suggests that obtaining a pte value

Re: [PATCH v4 1/4] drm/rockchip: vop: export line flag function

On Thu, Jul 14, 2016 at 12:15:44PM +0800, Yakir Yang wrote: > VOP have integrated a hardware counter which indicate the exact display > line that vop is scanning. And if we're interested in a specific line, > we can set the line number to vop line_flag register, and then vop would > generate a

Re: [PATCH v4 1/4] drm/rockchip: vop: export line flag function

On Thu, Jul 14, 2016 at 12:15:44PM +0800, Yakir Yang wrote: > VOP have integrated a hardware counter which indicate the exact display > line that vop is scanning. And if we're interested in a specific line, > we can set the line number to vop line_flag register, and then vop would > generate a

Re: [PATCH 2/4] mm: vmstat: account per-zone stalls and pages skipped during reclaim -fix

On 07/13/2016 12:00 PM, Mel Gorman wrote: As pointed out by Johannes -- the PG prefix seems to stand for page, and all stat names that contain it represent some per-page event. PGSTALL is not a page event. This patch renames it. This is a fix for the mmotm patch

Re: [PATCH 2/4] mm: vmstat: account per-zone stalls and pages skipped during reclaim -fix

On 07/13/2016 12:00 PM, Mel Gorman wrote: As pointed out by Johannes -- the PG prefix seems to stand for page, and all stat names that contain it represent some per-page event. PGSTALL is not a page event. This patch renames it. This is a fix for the mmotm patch

Re: [RFC 3/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_DEADLINE

On 07/14/2016 02:16 AM, Rasmus Villemoes wrote: The watchdog framework takes care of feeding a hardware watchdog until userspace opens /dev/watchdogN. If that never happens for some reason (buggy init script, corrupt root filesystem or whatnot) but the kernel itself is fine, the machine stays up

Re: [RFC 3/3] watchdog: introduce CONFIG_WATCHDOG_OPEN_DEADLINE

On 07/14/2016 02:16 AM, Rasmus Villemoes wrote: The watchdog framework takes care of feeding a hardware watchdog until userspace opens /dev/watchdogN. If that never happens for some reason (buggy init script, corrupt root filesystem or whatnot) but the kernel itself is fine, the machine stays up

Re: [Query] Preemption (hogging) of the work handler

On Thursday, July 14, 2016 04:39:39 PM Jan Kara wrote: > On Thu 14-07-16 16:33:38, Rafael J. Wysocki wrote: > > On Thursday, July 14, 2016 04:12:16 PM Jan Kara wrote: > > > On Wed 13-07-16 14:45:07, Sergey Senozhatsky wrote: > > > > Cc Petr Mladek. > > > > > > > > On (07/12/16 16:19), Viresh

Re: [Query] Preemption (hogging) of the work handler

On Thursday, July 14, 2016 04:39:39 PM Jan Kara wrote: > On Thu 14-07-16 16:33:38, Rafael J. Wysocki wrote: > > On Thursday, July 14, 2016 04:12:16 PM Jan Kara wrote: > > > On Wed 13-07-16 14:45:07, Sergey Senozhatsky wrote: > > > > Cc Petr Mladek. > > > > > > > > On (07/12/16 16:19), Viresh

Re: [PATCH v2 1/7] lib/dlock-list: Distributed and lock-protected lists

On Thu 14-07-16 07:50:43, Tejun Heo wrote: > > > > +void dlock_list_add(struct dlock_list_node *node, struct > > > > dlock_list_head *head) > > > > +{ > > > > + struct dlock_list_head *myhead; > > > > + > > > > + /* > > > > +* Disable preemption to make sure that CPU won't

Re: [PATCH v2 1/7] lib/dlock-list: Distributed and lock-protected lists

On Thu 14-07-16 07:50:43, Tejun Heo wrote: > > > > +void dlock_list_add(struct dlock_list_node *node, struct > > > > dlock_list_head *head) > > > > +{ > > > > + struct dlock_list_head *myhead; > > > > + > > > > + /* > > > > +* Disable preemption to make sure that CPU won't

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