From: "Joel Fernandes (Google)"
This patch detaches the preemptirq tracepoints from the tracers and
keeps it separate.
Advantages:
* Lockdep and irqsoff event can now run in parallel since they no longer
have their own calls.
* This unifies the usecase of adding hooks to an irqsoff and irqson
From: "Joel Fernandes (Google)"
In this patch we introduce a test module for simulating a long atomic
section in the kernel which the preemptoff or irqsoff tracers can
detect. This module is to be used only for test purposes and is default
disabled.
Following is the expected output (only
From: Paul McKenney
This is needed for a future tracepoint patch that uses srcu, and to make
sure it doesn't call into lockdep.
tracepoint code already calls notrace variants for rcu_read_lock_sched
so this patch does the same for srcu which will be used in a later
patch. Keeps it consistent
From: Paul McKenney
This is needed for a future tracepoint patch that uses srcu, and to make
sure it doesn't call into lockdep.
tracepoint code already calls notrace variants for rcu_read_lock_sched
so this patch does the same for srcu which will be used in a later
patch. Keeps it consistent
From: "Joel Fernandes (Google)"
Here we add unit tests for the preemptoff and irqsoff tracer by using a
kernel module introduced previously to trigger atomic sections in the
kernel.
Reviewed-by: Masami Hiramatsu
Acked-by: Masami Hiramatsu
Signed-off-by: Joel Fernandes (Google)
---
From: Paul McKenney
This is needed for a future tracepoint patch that uses srcu, and to make
sure it doesn't call into lockdep.
tracepoint code already calls notrace variants for rcu_read_lock_sched
so this patch does the same for srcu which will be used in a later
patch. Keeps it consistent
From: "Joel Fernandes (Google)"
Here we add unit tests for the preemptoff and irqsoff tracer by using a
kernel module introduced previously to trigger atomic sections in the
kernel.
Reviewed-by: Masami Hiramatsu
Acked-by: Masami Hiramatsu
Signed-off-by: Joel Fernandes (Google)
---
From: Paul McKenney
This is needed for a future tracepoint patch that uses srcu, and to make
sure it doesn't call into lockdep.
tracepoint code already calls notrace variants for rcu_read_lock_sched
so this patch does the same for srcu which will be used in a later
patch. Keeps it consistent
From: "Joel Fernandes (Google)"
This is a posting of v9 preempt/irq tracepoint clean up series rebased
onto v4.18-rc2. No changes in the series, just a rebase + repost.
All patches have a Reviewed-by tags now from reviewers. This series has
been well tested and is a simplification/refactoring
From: "Joel Fernandes (Google)"
This is a posting of v9 preempt/irq tracepoint clean up series rebased
onto v4.18-rc2. No changes in the series, just a rebase + repost.
All patches have a Reviewed-by tags now from reviewers. This series has
been well tested and is a simplification/refactoring
Sorry, ignore this version. Accidentally sent without version change.
On Thu, 2018-06-28 at 11:12 -0700, Srinivas Pandruvada wrote:
> In some of the recent platforms, it is possible that stand alone
> methods
> for HEBC() or other methods used in this driver may not exist. In
> this
> case
Sorry, ignore this version. Accidentally sent without version change.
On Thu, 2018-06-28 at 11:12 -0700, Srinivas Pandruvada wrote:
> In some of the recent platforms, it is possible that stand alone
> methods
> for HEBC() or other methods used in this driver may not exist. In
> this
> case
In some of the recent platforms, it is possible that stand alone methods
for HEBC() or other methods used in this driver may not exist. In this
case intel-hid driver will fail to load and power button will not be
functional.
It is also possible that some quirks in this driver added for some
In some of the recent platforms, it is possible that stand alone methods
for HEBC() or other methods used in this driver may not exist. In this
case intel-hid driver will fail to load and power button will not be
functional.
It is also possible that some quirks in this driver added for some
On Thu, Jun 28, 2018 at 2:13 PM Naga Sureshkumar Relli
wrote:
> > This driver has the same problem as the other patches:
> > use the ARM_AMBA primecell magic numbers detection, and the PrimeCell bus.
>
> Here the child is NAND controller and the parent is PL353 SMC,
> so do we need to update
On Thu, Jun 28, 2018 at 2:13 PM Naga Sureshkumar Relli
wrote:
> > This driver has the same problem as the other patches:
> > use the ARM_AMBA primecell magic numbers detection, and the PrimeCell bus.
>
> Here the child is NAND controller and the parent is PL353 SMC,
> so do we need to update
Add entry for Actions Semi OWL I2C driver and its binding under ARM/ACTIONS
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 09b54e9ebc6f..5084c62712fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@
Add Actions Semi OWL family S900 I2C driver.
Signed-off-by: Manivannan Sadhasivam
---
drivers/i2c/busses/Kconfig | 7 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-owl.c | 471 +++
3 files changed, 479 insertions(+)
create mode 100644
Add entry for Actions Semi OWL I2C driver and its binding under ARM/ACTIONS
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 09b54e9ebc6f..5084c62712fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@
Add Actions Semi OWL family S900 I2C driver.
Signed-off-by: Manivannan Sadhasivam
---
drivers/i2c/busses/Kconfig | 7 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-owl.c | 471 +++
3 files changed, 479 insertions(+)
create mode 100644
In some of the recent platforms, it is possible that stand alone methods
for HEBC() or other methods used in this driver may not exist. In this
case intel-hid driver will fail to load and power button will not be
functional.
It is also possible that some quirks in this driver added for some
In some of the recent platforms, it is possible that stand alone methods
for HEBC() or other methods used in this driver may not exist. In this
case intel-hid driver will fail to load and power button will not be
functional.
It is also possible that some quirks in this driver added for some
Add I2C controller nodes for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 60 +++
1 file changed, 60 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
Add pinctrl definition for Actions Semi S900 I2C controller. Pinctrl
definitions are only available for I2C0, I2C1, and I2C2.
Signed-off-by: Manivannan Sadhasivam
---
.../dts/actions/s900-bubblegum-96-pins.dtsi | 29 +++
1 file changed, 29 insertions(+)
create mode 100644
Add I2C controller nodes for Actions Semi S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 60 +++
1 file changed, 60 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
Add pinctrl definition for Actions Semi S900 I2C controller. Pinctrl
definitions are only available for I2C0, I2C1, and I2C2.
Signed-off-by: Manivannan Sadhasivam
---
.../dts/actions/s900-bubblegum-96-pins.dtsi | 29 +++
1 file changed, 29 insertions(+)
create mode 100644
Enable I2C1 and I2C2 exposed on the low speed expansion connector in
Bubblegum-96 board.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
Enable I2C1 and I2C2 exposed on the low speed expansion connector in
Bubblegum-96 board.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
Add devicetree binding for Actions Semi OWL I2C controller
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/i2c/i2c-owl.txt | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-owl.txt
diff --git
Add devicetree binding for Actions Semi OWL I2C controller
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/i2c/i2c-owl.txt | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-owl.txt
diff --git
This patchset adds I2C controller support for Actions Semi S900 SoC.
This driver has been structured in a way such that there will be only
one controller driver for the whole OWL family series (S500, S700 and
S900 SoCs).
There are 6 I2C controllers with separate memory mapped register space.
The
This patchset adds I2C controller support for Actions Semi S900 SoC.
This driver has been structured in a way such that there will be only
one controller driver for the whole OWL family series (S500, S700 and
S900 SoCs).
There are 6 I2C controllers with separate memory mapped register space.
The
On Thu, Jun 28, 2018 at 2:11 PM Naga Sureshkumar Relli
wrote:
> Sorry for the wrong name.
Hehe.
> > Hi Linux,
> Linus.
Everybody does this. Even myself.
Yours,
Linus Walleij
On Thu, Jun 28, 2018 at 2:11 PM Naga Sureshkumar Relli
wrote:
> Sorry for the wrong name.
Hehe.
> > Hi Linux,
> Linus.
Everybody does this. Even myself.
Yours,
Linus Walleij
Hello Mark,
On 06/28/2018 03:18 AM, Mark Brown wrote:
> On Wed, Jun 27, 2018 at 09:28:03AM -0700, Doug Anderson wrote:
>
>> OK, great. I guess I'm confused about the "|| COMPILE_TEST" causing
>> problems then? I was worried that anyone trying to do "COMPILE_TEST"
>> on your tree (or linuxnext
Hello Mark,
On 06/28/2018 03:18 AM, Mark Brown wrote:
> On Wed, Jun 27, 2018 at 09:28:03AM -0700, Doug Anderson wrote:
>
>> OK, great. I guess I'm confused about the "|| COMPILE_TEST" causing
>> problems then? I was worried that anyone trying to do "COMPILE_TEST"
>> on your tree (or linuxnext
On Wed, Jun 27, 2018 at 10:10:28PM -0700, Joel Fernandes wrote:
> On Wed, Jun 27, 2018 at 11:27:26AM -0700, Joel Fernandes wrote:
> [..]
> > > > > s = __ALIGN_MASK(s, RCU_SEQ_STATE_MASK);
> > > > >
> > > >
> > > > I agree with Peter's suggestions for both the verbiage reduction in the
> >
On Wed, Jun 27, 2018 at 10:10:28PM -0700, Joel Fernandes wrote:
> On Wed, Jun 27, 2018 at 11:27:26AM -0700, Joel Fernandes wrote:
> [..]
> > > > > s = __ALIGN_MASK(s, RCU_SEQ_STATE_MASK);
> > > > >
> > > >
> > > > I agree with Peter's suggestions for both the verbiage reduction in the
> >
From: Borislav Petkov
This is an AMD-specific MSR. Put it where it belongs.
Signed-off-by: Borislav Petkov
---
arch/x86/kvm/svm.c | 14 ++
arch/x86/kvm/x86.c | 12
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
From: Borislav Petkov
This is an AMD-specific MSR. Put it where it belongs.
Signed-off-by: Borislav Petkov
---
arch/x86/kvm/svm.c | 14 ++
arch/x86/kvm/x86.c | 12
2 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
From: Borislav Petkov
The hardware configuration register has some useful bits which can be
used by guests. Implement McStatusWrEn which can be used by guests when
injecting MCEs with the in-kernel mce-inject module.
For that, we need to set bit 18 - McStatusWrEn - first, before writing
the
From: Borislav Petkov
The hardware configuration register has some useful bits which can be
used by guests. Implement McStatusWrEn which can be used by guests when
injecting MCEs with the in-kernel mce-inject module.
For that, we need to set bit 18 - McStatusWrEn - first, before writing
the
From: Borislav Petkov
Hi all,
here's v2, dropping patch 3 and incorporating hopefully all of Radim's
feedback.
Thx.
v1 cover letter:
there's this mce-inject.ko module in the kernel which allows for
injecting real MCEs and thus test the MCE handling code.
It is doubly useful to be able to
From: Borislav Petkov
Hi all,
here's v2, dropping patch 3 and incorporating hopefully all of Radim's
feedback.
Thx.
v1 cover letter:
there's this mce-inject.ko module in the kernel which allows for
injecting real MCEs and thus test the MCE handling code.
It is doubly useful to be able to
In sparse_init() we allocate two large buffers to temporary hold usemap and
memmap for the whole machine. However, we can avoid doing that if we
changed sparse_init() to operated on per-node bases instead of doing it on
the whole machine beforehand.
As shown by Baoquan
In sparse_init() we allocate two large buffers to temporary hold usemap and
memmap for the whole machine. However, we can avoid doing that if we
changed sparse_init() to operated on per-node bases instead of doing it on
the whole machine beforehand.
As shown by Baoquan
sparse_init() requires to temporary allocate two large buffers:
usemap_map and map_map. Baoquan He has identified that these buffers are so
large that Linux is not bootable on small memory machines, such as a kdump
boot.
Baoquan provided a fix, which reduces these sizes of these buffers, but it
sparse_init() requires to temporary allocate two large buffers:
usemap_map and map_map. Baoquan He has identified that these buffers are so
large that Linux is not bootable on small memory machines, such as a kdump
boot.
Baoquan provided a fix, which reduces these sizes of these buffers, but it
On Thu, Jun 28, 2018 at 05:30:51PM +0100, Sudeep Holla wrote:
> I am not sure if we can ever guarantee that DT and ACPI will get the
> same ids whatever counter we use as it depends on the order presented in
> the firmware(DT or ACPI). So I am not for generating ids for core and
> threads in that
On Thu, Jun 28, 2018 at 05:30:51PM +0100, Sudeep Holla wrote:
> I am not sure if we can ever guarantee that DT and ACPI will get the
> same ids whatever counter we use as it depends on the order presented in
> the firmware(DT or ACPI). So I am not for generating ids for core and
> threads in that
Change sprase_init() to only find the pnum ranges that belong to a specific
node and call sprase_init_nid() for that range from sparse_init().
Delete all the code that became obsolete with this change.
Signed-off-by: Pavel Tatashin
---
include/linux/mm.h | 5 -
mm/sparse-vmemmap.c | 39
Change sprase_init() to only find the pnum ranges that belong to a specific
node and call sprase_init_nid() for that range from sparse_init().
Delete all the code that became obsolete with this change.
Signed-off-by: Pavel Tatashin
---
include/linux/mm.h | 5 -
mm/sparse-vmemmap.c | 39
22: 0f 01 c3 vmresume
25: 48 89 4c 24 08mov%rcx,0x8(%rsp)
2a: 59pop%rcx
:
2b: 0f 96 81 88 56 00 00 setbe 0x5688(%rcx)
32: 48 89 81 00 03 00 00 mov%rax,0x300(%rcx)
39: 48 89 99 18 03 00 00 mov%rbx,0x318(%rcx)
%rcx should be
22: 0f 01 c3 vmresume
25: 48 89 4c 24 08mov%rcx,0x8(%rsp)
2a: 59pop%rcx
:
2b: 0f 96 81 88 56 00 00 setbe 0x5688(%rcx)
32: 48 89 81 00 03 00 00 mov%rax,0x300(%rcx)
39: 48 89 99 18 03 00 00 mov%rbx,0x318(%rcx)
%rcx should be
On 06/28/2018 10:48 AM, Morten Rasmussen wrote:
On Wed, Jun 27, 2018 at 05:41:22PM +0200, Dietmar Eggemann wrote:
On 06/22/2018 04:36 PM, Morten Rasmussen wrote:
On Fri, Jun 22, 2018 at 09:22:22AM +0100, Quentin Perret wrote:
[...]
What would happen if you hotplugged an entire cluster ?
On 06/28/2018 10:48 AM, Morten Rasmussen wrote:
On Wed, Jun 27, 2018 at 05:41:22PM +0200, Dietmar Eggemann wrote:
On 06/22/2018 04:36 PM, Morten Rasmussen wrote:
On Fri, Jun 22, 2018 at 09:22:22AM +0100, Quentin Perret wrote:
[...]
What would happen if you hotplugged an entire cluster ?
Quoting Linus Walleij (2018-06-28 07:25:46)
> On Fri, Jun 22, 2018 at 8:29 PM Bjorn Andersson
> wrote:
> > On Fri 22 Jun 10:58 PDT 2018, Bjorn Andersson wrote:
> > > On Mon 18 Jun 13:52 PDT 2018, Stephen Boyd wrote:
> > >
> > > > We rely on devices to use pinmuxing configurations in DT to select
Quoting Linus Walleij (2018-06-28 07:25:46)
> On Fri, Jun 22, 2018 at 8:29 PM Bjorn Andersson
> wrote:
> > On Fri 22 Jun 10:58 PDT 2018, Bjorn Andersson wrote:
> > > On Mon 18 Jun 13:52 PDT 2018, Stephen Boyd wrote:
> > >
> > > > We rely on devices to use pinmuxing configurations in DT to select
Hi,
On 06/28/2018 11:30 AM, Sudeep Holla wrote:
On 28/06/18 15:51, Andrew Jones wrote:
When booting with devicetree, and the devicetree has the cpu-map
node, the topology IDs that are visible from sysfs are generated
with counters. ACPI, on the other hand, uses ACPI table pointer
offsets,
Hi,
On 06/28/2018 11:30 AM, Sudeep Holla wrote:
On 28/06/18 15:51, Andrew Jones wrote:
When booting with devicetree, and the devicetree has the cpu-map
node, the topology IDs that are visible from sysfs are generated
with counters. ACPI, on the other hand, uses ACPI table pointer
offsets,
On Tue, May 08, 2018 at 10:49:46PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in dev_err error message
>
> Signed-off-by: Colin Ian King
> ---
> drivers/pci/host/pci-hyperv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Colin,
patch
On Tue, May 08, 2018 at 10:49:46PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in dev_err error message
>
> Signed-off-by: Colin Ian King
> ---
> drivers/pci/host/pci-hyperv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Colin,
patch
Whether any of the conditions is true or not, the return variable
is always set to rtw_resume_process(padapter). Replace the if else
construct with a single call to rtw_resume_process(). Also remove
the now unused local variable pwrpriv.
Signed-off-by: Michael Straube
---
Whether any of the conditions is true or not, the return variable
is always set to rtw_resume_process(padapter). Replace the if else
construct with a single call to rtw_resume_process(). Also remove
the now unused local variable pwrpriv.
Signed-off-by: Michael Straube
---
Hi Mathieu,
On Thu, Jun 28, 2018 at 12:23:59PM -0400, Mathieu Desnoyers wrote:
> On 32-bit kernels, the rseq->rseq_cs_padding field is never read by the
> kernel. However, 64-bit kernels dealing with 32-bit compat tasks read the
> full 64-bit in its entirety, and terminates the offending process
Hi Mathieu,
On Thu, Jun 28, 2018 at 12:23:59PM -0400, Mathieu Desnoyers wrote:
> On 32-bit kernels, the rseq->rseq_cs_padding field is never read by the
> kernel. However, 64-bit kernels dealing with 32-bit compat tasks read the
> full 64-bit in its entirety, and terminates the offending process
> 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation
>
> The above patches need at least one additional Acked-by
> or Reviewed-by. If any of you gets a chance, please do
> look them over.
Glad this came out. ;-)
No objection to the patch: feel free to add
BPF_MAP_TYPE_CGROUP_STORAGE maps are special in a way
that the access from the bpf program side is lookup-free.
That means the result is guaranteed to be a valid
pointer to the cgroup storage; no NULL-check is required.
This patch introduces BPF_PTR_TO_MAP_VALUE return type,
which is required to
> 1bc179880fba docs: atomic_ops: Describe atomic_set as a write operation
>
> The above patches need at least one additional Acked-by
> or Reviewed-by. If any of you gets a chance, please do
> look them over.
Glad this came out. ;-)
No objection to the patch: feel free to add
BPF_MAP_TYPE_CGROUP_STORAGE maps are special in a way
that the access from the bpf program side is lookup-free.
That means the result is guaranteed to be a valid
pointer to the cgroup storage; no NULL-check is required.
This patch introduces BPF_PTR_TO_MAP_VALUE return type,
which is required to
On Wed, Jun 27, 2018 at 09:15:31AM -0700, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 10:42:01AM +0800, Boqun Feng wrote:
> > On Tue, Jun 26, 2018 at 12:27:47PM -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 26, 2018 at 07:46:52PM +0800, Boqun Feng wrote:
> > > > On Tue, Jun 26, 2018 at
On Wed, Jun 27, 2018 at 09:15:31AM -0700, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 10:42:01AM +0800, Boqun Feng wrote:
> > On Tue, Jun 26, 2018 at 12:27:47PM -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 26, 2018 at 07:46:52PM +0800, Boqun Feng wrote:
> > > > On Tue, Jun 26, 2018 at
Hi Mathieu,
On Tue, Jun 26, 2018 at 12:11:52PM -0400, Mathieu Desnoyers wrote:
> - On Jun 26, 2018, at 11:14 AM, Will Deacon will.dea...@arm.com wrote:
> > On Mon, Jun 25, 2018 at 02:10:10PM -0400, Mathieu Desnoyers wrote:
> >> I notice you are using the instructions
> >>
> >> adrp
> >>
Hi Mathieu,
On Tue, Jun 26, 2018 at 12:11:52PM -0400, Mathieu Desnoyers wrote:
> - On Jun 26, 2018, at 11:14 AM, Will Deacon will.dea...@arm.com wrote:
> > On Mon, Jun 25, 2018 at 02:10:10PM -0400, Mathieu Desnoyers wrote:
> >> I notice you are using the instructions
> >>
> >> adrp
> >>
On 28/06/18 16:44, Yang, Shunyong wrote:
> Hi, All
>
>> On Jun 28, 2018, at 22:51, Andrew Jones
>> wrote:
>>
>>> On Thu, Jun 28, 2018 at 03:09:19PM +0100, Sudeep Holla wrote:
>>>
>>>
On 28/06/18 14:19, Jeremy Linton wrote: Hi,
On 06/28/2018 07:12 AM, Sudeep Holla wrote:
>>>
>>>
On 28/06/18 16:44, Yang, Shunyong wrote:
> Hi, All
>
>> On Jun 28, 2018, at 22:51, Andrew Jones
>> wrote:
>>
>>> On Thu, Jun 28, 2018 at 03:09:19PM +0100, Sudeep Holla wrote:
>>>
>>>
On 28/06/18 14:19, Jeremy Linton wrote: Hi,
On 06/28/2018 07:12 AM, Sudeep Holla wrote:
>>>
>>>
On Thu, Jun 28, 2018 at 06:33:24PM +0200, Frederic Weisbecker wrote:
> On Wed, Jun 27, 2018 at 07:25:29AM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 27, 2018 at 12:40:15PM +0200, Frederic Weisbecker wrote:
> > > On Tue, Jun 26, 2018 at 10:48:26AM -0700, Paul E. McKenney wrote:
> > > > On Tue,
On Thu, Jun 28, 2018 at 06:33:24PM +0200, Frederic Weisbecker wrote:
> On Wed, Jun 27, 2018 at 07:25:29AM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 27, 2018 at 12:40:15PM +0200, Frederic Weisbecker wrote:
> > > On Tue, Jun 26, 2018 at 10:48:26AM -0700, Paul E. McKenney wrote:
> > > > On Tue,
This change avoids needlessly searching for more timers in
run_local_timers() (hard interrupt context) when they can't fire.
For example, when ktimersoftd/run_timer_softirq() is scheduled but
preempted due to cpu contention. When it runs, run_timer_softirq() will
discover newly expired timers up
This change avoids needlessly searching for more timers in
run_local_timers() (hard interrupt context) when they can't fire.
For example, when ktimersoftd/run_timer_softirq() is scheduled but
preempted due to cpu contention. When it runs, run_timer_softirq() will
discover newly expired timers up
Collect expired timers in interrupt context to avoid overhead of waking
ktimersoftd on every scheduler tick.
This is implemented by storing lists of expired timers in the timer_base
struct, which is updated by the interrupt routing on each tick in
run_local_timers(). TIMER softirq (ktimersoftd)
Collect expired timers in interrupt context to avoid overhead of waking
ktimersoftd on every scheduler tick.
This is implemented by storing lists of expired timers in the timer_base
struct, which is updated by the interrupt routing on each tick in
run_local_timers(). TIMER softirq (ktimersoftd)
I found the problem: Running `dumpcap -D` (E.g. by wireshark) creates a
timer that's sometimes re-armed with 0 timeout in it's callback function
prb_retire_rx_blk_timer_expired(). My change introduced a subtle change
in __run_timers()'s stop condition, which causes ktimersoftd to spin
when
I found the problem: Running `dumpcap -D` (E.g. by wireshark) creates a
timer that's sometimes re-armed with 0 timeout in it's callback function
prb_retire_rx_blk_timer_expired(). My change introduced a subtle change
in __run_timers()'s stop condition, which causes ktimersoftd to spin
when
This renames usbphy nodes 2 & 3, so that they follow the same
format as usbphy node 0 & 1 from imx53.dtsi.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/imx53-ppd.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-ppd.dts
Add information about 3V3 power rail to avoid kernel warnings,
that dummy regulators have been added.
Signed-off-by: Sebastian Reichel
---
Changes since PATCHv1:
* split usbphy rename into its own patch
* drop useless regulator-boot-on
---
arch/arm/boot/dts/imx53-ppd.dts | 32
This renames usbphy nodes 2 & 3, so that they follow the same
format as usbphy node 0 & 1 from imx53.dtsi.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/imx53-ppd.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-ppd.dts
Add information about 3V3 power rail to avoid kernel warnings,
that dummy regulators have been added.
Signed-off-by: Sebastian Reichel
---
Changes since PATCHv1:
* split usbphy rename into its own patch
* drop useless regulator-boot-on
---
arch/arm/boot/dts/imx53-ppd.dts | 32
On Wed, Jun 27, 2018 at 07:25:29AM -0700, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 12:40:15PM +0200, Frederic Weisbecker wrote:
> > On Tue, Jun 26, 2018 at 10:48:26AM -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 26, 2018 at 06:32:55PM +0200, Peter Zijlstra wrote:
> > > > On Tue, Jun
On Wed, Jun 27, 2018 at 07:25:29AM -0700, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 12:40:15PM +0200, Frederic Weisbecker wrote:
> > On Tue, Jun 26, 2018 at 10:48:26AM -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 26, 2018 at 06:32:55PM +0200, Peter Zijlstra wrote:
> > > > On Tue, Jun
On 28/06/18 15:51, Andrew Jones wrote:
> When booting with devicetree, and the devicetree has the cpu-map
> node, the topology IDs that are visible from sysfs are generated
> with counters. ACPI, on the other hand, uses ACPI table pointer
> offsets, which, while guaranteed to be unique, look a
On 28/06/18 15:51, Andrew Jones wrote:
> When booting with devicetree, and the devicetree has the cpu-map
> node, the topology IDs that are visible from sysfs are generated
> with counters. ACPI, on the other hand, uses ACPI table pointer
> offsets, which, while guaranteed to be unique, look a
Some people have reported that the warning in sched_tick_remote()
occasionally triggers, especially in favour of some RCU-Torture
pressure:
WARNING: CPU: 11 PID: 906 at kernel/sched/core.c:3138
sched_tick_remote+0xb6/0xc0
Modules linked in:
CPU: 11 PID: 906 Comm:
Some people have reported that the warning in sched_tick_remote()
occasionally triggers, especially in favour of some RCU-Torture
pressure:
WARNING: CPU: 11 PID: 906 at kernel/sched/core.c:3138
sched_tick_remote+0xb6/0xc0
Modules linked in:
CPU: 11 PID: 906 Comm:
Vitaly Kuznetsov writes:
> Wanpeng Li writes:
>
>> Hi Vitaly, (fix my reply mess this time)
>> On Sat, 23 Jun 2018 at 01:09, Vitaly Kuznetsov wrote:
>>>
>>> When reviewing my "x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_
>>> {LIST,SPACE} hypercalls when possible" patch Michael
Vitaly Kuznetsov writes:
> Wanpeng Li writes:
>
>> Hi Vitaly, (fix my reply mess this time)
>> On Sat, 23 Jun 2018 at 01:09, Vitaly Kuznetsov wrote:
>>>
>>> When reviewing my "x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_
>>> {LIST,SPACE} hypercalls when possible" patch Michael
On 32-bit kernels, the rseq->rseq_cs_padding field is never read by the
kernel. However, 64-bit kernels dealing with 32-bit compat tasks read the
full 64-bit in its entirety, and terminates the offending process with
a segmentation fault if the upper 32 bits are set due to failure of
On 32-bit kernels, the rseq->rseq_cs_padding field is never read by the
kernel. However, 64-bit kernels dealing with 32-bit compat tasks read the
full 64-bit in its entirety, and terminates the offending process with
a segmentation fault if the upper 32 bits are set due to failure of
On Thu, Jun 28, 2018 at 04:08:24PM +, Wangxuefeng (E) wrote:
> Hi, mark
> Your means is that DMB must make sure the completion of prior load/store
> or CMO and make sure the data is visible to all obsevers (no matter device or
> cacheable). DMB not only keep order?
Not quite -- DMB
On Thu, Jun 28, 2018 at 04:08:24PM +, Wangxuefeng (E) wrote:
> Hi, mark
> Your means is that DMB must make sure the completion of prior load/store
> or CMO and make sure the data is visible to all obsevers (no matter device or
> cacheable). DMB not only keep order?
Not quite -- DMB
401 - 500 of 1130 matches
Mail list logo
