Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Daniel Bristot de Oliveira
On 9/24/20 10:27 AM, pet...@infradead.org wrote: > So my current todo list is: > > - Change RT PULL > - Change DL PULL > - Add migrate_disable() tracer; exactly like preempt/irqoff, except >measuring task-runtime instead of cpu-time. > - Add a mode that measures actual interference. > -

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Steven Rostedt
On Thu, 24 Sep 2020 19:55:10 +0200 Thomas Gleixner wrote: > On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote: > > On Thu, 24 Sep 2020 08:57:52 +0200 > > Thomas Gleixner wrote: > > > >> > Now as for migration disabled nesting, at least now we would have > >> > groupings of this, and perhaps

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Thomas Gleixner
On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote: > On Thu, 24 Sep 2020 08:57:52 +0200 > Thomas Gleixner wrote: > >> > Now as for migration disabled nesting, at least now we would have >> > groupings of this, and perhaps the theorists can handle that. I mean, >> > how is this much different

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Peter Zijlstra
On Thu, Sep 24, 2020 at 09:51:38AM -0400, Steven Rostedt wrote: > > It turns out, that getting selected for pull-balance is exactly that > > condition, and clearly a migrate_disable() task cannot be pulled, but we > > can use that signal to try and pull away the running task that's in the > >

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Steven Rostedt
On Thu, 24 Sep 2020 14:42:41 +0200 Peter Zijlstra wrote: > On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote: > > Anyway, instead of blocking. What about having a counter of number of > > migrate disabled tasks per cpu, and when taking a migrate_disable(), and > > there's > >

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Peter Zijlstra
On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote: > Anyway, instead of blocking. What about having a counter of number of > migrate disabled tasks per cpu, and when taking a migrate_disable(), and > there's > already another task with migrate_disabled() set, and the current task has

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Steven Rostedt
On Thu, 24 Sep 2020 08:57:52 +0200 Thomas Gleixner wrote: > > Now as for migration disabled nesting, at least now we would have > > groupings of this, and perhaps the theorists can handle that. I mean, > > how is this much different that having a bunch of tasks blocked on a > > mutex with the

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread peterz
On Wed, Sep 23, 2020 at 11:52:51AM -0400, Steven Rostedt wrote: > On Wed, 23 Sep 2020 10:40:32 +0200 > pet...@infradead.org wrote: > > > However, with migrate_disable() we can have each task preempted in a > > migrate_disable() region, worse we can stack them all on the _same_ CPU > > (super

[PATCH v6 4/6] dt-bindings: dw-apb-ictl: support hierarchy irq domain

2020-09-24 Thread Zhen Lei
Add support to use dw-apb-ictl as primary interrupt controller. Signed-off-by: Zhen Lei Reviewed-by: Rob Herring --- .../bindings/interrupt-controller/snps,dw-apb-ictl.txt | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git

[PATCH v6 0/6] irqchip: dw-apb-ictl: support hierarchy irq domain

2020-09-24 Thread Zhen Lei
v5 --> v6: 1. add Reviewed-by: Rob Herring for Patch 4. 2. Some modifications are made to Patch 5: 1) add " |" for each "description:" property if its content exceeds one line, to tell the yaml keep the "newline" character. 2) add "..." to mark the end of the yaml file. 3) Change

[PATCH v6 6/6] ARC: [dts] fix the errors detected by dtbs_check

2020-09-24 Thread Zhen Lei
xxx/arc/boot/dts/axs101.dt.yaml: dw-apb-ictl@e0012000: $nodename:0: \ 'dw-apb-ictl@e0012000' does not match '^interrupt-controller(@[0-9a-f,]+)*$' >From schema: xxx/interrupt-controller/snps,dw-apb-ictl.yaml The node name of the interrupt controller must start with "interrupt-controller" instead

[PATCH v6 2/6] irqchip: dw-apb-ictl: prepare for support hierarchy irq domain

2020-09-24 Thread Zhen Lei
Rename some functions and variables in advance, to make the next patch looks more clear. The details are as follows: 1. rename dw_apb_ictl_handler() to dw_apb_ictl_handle_irq_cascaded(). 2. change (1 << hwirq) to BIT(hwirq). In function dw_apb_ictl_init(): 1. rename local variable irq to

[PATCH v6 5/6] dt-bindings: dw-apb-ictl: convert to json-schema

2020-09-24 Thread Zhen Lei
Convert the Synopsys DesignWare APB interrupt controller (dw_apb_ictl) binding to DT schema format using json-schema. Signed-off-by: Zhen Lei --- .../interrupt-controller/snps,dw-apb-ictl.txt | 43 - .../interrupt-controller/snps,dw-apb-ictl.yaml | 74 ++

[PATCH v6 3/6] irqchip: dw-apb-ictl: support hierarchy irq domain

2020-09-24 Thread Zhen Lei
Add support to use dw-apb-ictl as primary interrupt controller. Suggested-by: Marc Zyngier Signed-off-by: Zhen Lei Tested-by: Haoyu Lv --- drivers/irqchip/Kconfig | 2 +- drivers/irqchip/irq-dw-apb-ictl.c | 74 ++- 2 files changed, 67

[PATCH v6 1/6] genirq: define an empty function set_handle_irq() if !GENERIC_IRQ_MULTI_HANDLER

2020-09-24 Thread Zhen Lei
To avoid compilation error if an irqchip driver references the function set_handle_irq() but may not select GENERIC_IRQ_MULTI_HANDLER on some systems. For example, the Synopsys DesignWare APB interrupt controller (dw_apb_ictl) is used as the secondary interrupt controller on arc, csky, arm64, and

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-24 Thread Thomas Gleixner
On Wed, Sep 23 2020 at 17:12, Steven Rostedt wrote: > On Wed, 23 Sep 2020 22:55:54 +0200 > Then scratch the idea of having anonymous local_lock() and just bring > local_lock in directly? Then have a kmap local lock, which would only > block those that need to do a kmap. That's still going to end