On Wed, Mar 17 2021 at 15:48, Sebastian Andrzej Siewior wrote:
> On 2021-03-17 15:38:52 [+0100], Thomas Gleixner wrote:
>> thread(irq_A)
>> irq_handler(A)
>> spin_lock(&foo->lock);
>>
>> interrupt(irq_B)
>> irq_handler(B)
>> spin_lo
rence.
For RT kernels there is no issue.
Fixes: 8d32a307e4fa ("genirq: Provide forced interrupt threading")
Reported-by: Johan Hovold
Signed-off-by: Thomas Gleixner
Cc: Eric Dumazet
Cc: Sebastian Andrzej Siewior
Cc: netdev
Cc: "David S. Miller"
Cc: Krzysztof Kozlowski
On Thu, Apr 16 2020 at 15:59, Sebastian Andrzej Siewior wrote:
> any comments from the timer department?
Yes.
> On 2019-11-27 18:37:19 [+0100], To Eric Dumazet wrote:
>> On 2019-11-27 09:11:40 [-0800], Eric Dumazet wrote:
>> > Resent in non HTML mode :/
>> don't worry, mutt handles both :)
>>
>>
On Tue, Mar 09 2021 at 16:21, Sebastian Andrzej Siewior wrote:
> On 2021-03-09 16:00:37 [+0100], To Thomas Gleixner wrote:
>> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
>> index 07c7329d21aa7..1c14ccd351091 100644
>> --- a/include/linux/interrupt.h
&
is scheduled
out.
tasklet_kill() is used in teardown paths and not performance critical at
all. Replace the spin wait with wait_var_event().
Signed-off-by: Peter Zijlstra
Signed-off-by: Thomas Gleixner
---
kernel/softirq.c | 23 +++
1 file changed, 15 insertions(+), 8
-- NOT FOR IMMEDIATE MERGING --
Now that all users of tasklet_disable() are invoked from sleepable context,
convert it to use tasklet_unlock_wait() which might sleep.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a
driver, so use
tasklet_disable_in_atomic() which allows to make tasklet_disable()
sleepable once the remaining atomic users are addressed.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei Liu
C
Siewior
Signed-off-by: Thomas Gleixner
Cc: Stefan Richter
Cc: linux1394-de...@lists.sourceforge.net
---
drivers/firewire/ohci.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -2545,7 +2545,7 @@ static int
tasklet_disable_in_atomic() which allows
tasklet_disable() to be made sleepable once the remaining atomic context
usage sites are cleaned up.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Chas Williams <3ch...@gmail.com>
Cc: linux-atm-gene...@lists.sourceforge.
It's unclear how that can be distangled, so use tasklet_disable_in_atomic()
for now. This allows tasklet_disable() to become sleepable once the
remaining atomic users are cleaned up.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: ath9k-de...@qca.qualcomm.com
become sleeping.
Replace the linkch_task tasklet with a work.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
---
drivers/net/ethernet/jme.c | 10 +-
drivers/net/ethernet/jme.h |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/net
s are converted.
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Cc: Denis Kirjanov
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: netdev@vger.kernel.org
---
drivers/net/ethernet/dlink/sundance.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
processed on a different CPU
then the local_bh_disable()/enable() pair is just a waste of processor
cycles.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
---
include/linux/interrupt.h |2 +-
kernel/softirq.c | 28 +++-
2 files changed, 28
fixed up and will be
converted to the sleep wait variant later.
Signed-off-by: Peter Zijlstra
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h | 13 ++---
kernel/softirq.c | 18 ++
2 files changed, 20 insertions(+), 11 deletions(-)
--- a/include
To ease the transition use spin waiting in tasklet_disable() until all
usage sites from atomic context have been cleaned up.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/include/linux/interrupt.h
+++ b/include
A barrier() in a tight loop which waits for something to happen on a remote
CPU is a pointless exercise. Replace it with cpu_relax() which allows HT
siblings to make progress.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
---
include/linux/interrupt.h |3 ++-
1 file
This is a follow up to the review comments of the series which makes
softirq processing PREEMPT_RT safe:
https://lore.kernel.org/r/20201207114743.gk3...@hirez.programming.kicks-ass.net
Peter suggested to replace the spin waiting in tasklet_disable() and
tasklet_kill() with wait_event(). This als
() to
convert the few atomic use cases over, which allows to change
tasklet_disable() and tasklet_unlock_wait() in a later step.
Signed-off-by: Thomas Gleixner
---
include/linux/interrupt.h | 22 ++
1 file changed, 22 insertions(+)
--- a/include/linux/interrupt.h
+++ b
Inlines exist for a reason.
Signed-off-by: Thomas Gleixner
Tested-by: Sebastian Andrzej Siewior
---
include/linux/interrupt.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -676,9 +676,9 @@ static inline void
On Sun, Dec 27 2020 at 11:20, Guenter Roeck wrote:
> On Thu, Dec 10, 2020 at 08:25:38PM +0100, Thomas Gleixner wrote:
> Yes, but that means that irq_check_status_bit() may be called from modules,
> but it is not exported, resulting in build errors such as the following.
>
> arm
On Wed, Dec 16 2020 at 15:55, Naresh Kamboju wrote:
> On Tue, 15 Dec 2020 at 23:52, Jakub Kicinski wrote:
>> > Or you could place checks for being in a BH-disable further up in
>> > the code. Or build with CONFIG_DEBUG_INFO=y to allow more precise
>> > interpretation of this stack trace.
>
> I wi
Andrew,
On Fri, Dec 11 2020 at 22:21, Andrew Cooper wrote:
> On 11/12/2020 21:27, Thomas Gleixner wrote:
>> It's not any different from the hardware example at least not as far as
>> I understood the code.
>
> Xen's event channels do have a couple of quirks.
Why am
On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote:
> On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
>
>> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote:
>>>
>>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
>>>
On Fri, Dec 11 2020 at 09:29, boris ostrovsky wrote:
> On 12/11/20 7:37 AM, Thomas Gleixner wrote:
>> On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote:
>>> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
>>>> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>>&
On Fri, Dec 11 2020 at 14:19, David Laight wrote:
> From: Thomas Gleixner
>> You can't catch that. If this really becomes an issue you need a
>> sequence counter around it.
>
> Or just two copies of the high word.
> Provided the accesses are sequenced:
> writer:
&
On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote:
>>
>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
>> be exported. Move it into the core code which lifts another requirem
On Fri, Dec 11 2020 at 10:13, Tvrtko Ursulin wrote:
> On 10/12/2020 19:25, Thomas Gleixner wrote:
>>
>> Aside of that the count is per interrupt line and therefore takes
>> interrupts from other devices into account which share the interrupt line
>> and are not han
On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote:
> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
>>
>> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>>> All event channel setups bind the interrupt on CPU0 or the target CPU for
>>> percpu interrupts and ove
On Fri, Dec 11 2020 at 07:17, Jürgen Groß wrote:
> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
>>
>> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>>> All event channel setups bind the interrupt on CPU0 or the target CPU for
>>> percpu interrupts and ove
On Thu, Dec 10 2020 at 18:20, boris ostrovsky wrote:
> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>> All event channel setups bind the interrupt on CPU0 or the target CPU for
>> percpu interrupts and overwrite the affinity mask with the corresponding
>> cpumask. Tha
On Thu, Dec 10 2020 at 18:19, boris ostrovsky wrote:
> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>> -EXPORT_SYMBOL_GPL(bind_evtchn_to_irq_lateeoi);
>
> include/xen/events.h also needs to be updated (and in the next patch for
> xen_set_affinity_evtchn() as well).
Darn, I lost that.
.
Signed-off-by: Thomas Gleixner
---
arch/alpha/kernel/sys_jensen.c |2 +-
arch/x86/kernel/topology.c |1 +
include/linux/interrupt.h |1 +
include/linux/irqdesc.h|7 +--
kernel/irq/manage.c| 17 +
5 files changed, 21 insertions
irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
be exported. Move it into the core code which lifts another requirement for
the export.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h | 10 --
kernel/irq/irqdesc.c| 14 ++
2 files
The SMP variant works perfectly fine on UP as well.
Signed-off-by: Thomas Gleixner
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: afzal mohammed
Cc: linux-par...@vger.kernel.org
---
arch/parisc/kernel/irq.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/a
No more users outside the core code.
Signed-off-by: Thomas Gleixner
---
include/linux/kernel_stat.h |1 -
kernel/irq/irqdesc.c| 19 ++-
2 files changed, 6 insertions(+), 14 deletions(-)
--- a/include/linux/kernel_stat.h
+++ b/include/linux/kernel_stat.h
@@ -67,7
These checks are used by modules and prevent the removal of the export of
irq_to_desc(). Move the accessor into the core.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h | 17 +
kernel/irq/manage.c | 17 +
2 files changed, 22 insertions(+), 12
means that checking the affinity mask itself does not really tell
about the actual target CPUs.
Signed-off-by: Thomas Gleixner
Cc: Tariq Toukan
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: netdev@vger.kernel.org
Cc: linux-r...@vger.kernel.org
---
drivers/net/ethernet/mellanox/ml
chip data of the top level chip of a hierarchy. It does not
matter in this case because the chip is the top level chip, but that
doesn't make it more correct.
Signed-off-by: Thomas Gleixner
Cc: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Michal Simek
Cc: linux-...@vger.kerne
contain cpumask_of(0).
As the CPU0 enforcement was in place _before_ this was implemented it's
entirely unclear how that can ever have worked at all.
Remove it as preparation for doing it proper.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: x
makes XEN on x86 use the same mechanics as on e.g. ARM64 where
deferred affinity setting is not required and not implemented and the code
path in the ack functions is compiled out.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de
Most users of kstat_irqs_cpu() have the irq descriptor already. No point in
calling into the core code and looking it up once more.
Use it in per_cpu_count_show() to start with.
Signed-off-by: Thomas Gleixner
---
include/linux/irqdesc.h |6 ++
kernel/irq/irqdesc.c|4 ++--
2
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: afzal mohammed
Cc: linux-par...@vger.kernel.org
---
arch/parisc/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: Mark Rutland
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/kernel/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: Christian Borntraeger
Cc: Heiko Carstens
Cc: linux-s...@vger.kernel.org
---
arch/s390/kernel/irq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/s390/kernel/irq.c
+++ b
Nothing uses the result and nothing should ever use it in driver code.
Signed-off-by: Thomas Gleixner
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: Pankaj Bharadiya
Cc: Chris Wilson
Cc: Wambui Karuga
Cc: intel-...@lists.freedesktop.org
Cc
chip data of the top level chip of a hierarchy. It does not
matter in this case because the chip is the top level chip, but that
doesn't make it more correct.
Signed-off-by: Thomas Gleixner
Cc: Karthikeyan Mitran
Cc: Hou Zhiqiang
Cc: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Bjorn Helgaa
on of subsystem
boundaries and racy against concurrent modifications of the interrupt
descriptor.
Print the irq line instead so the information can be looked up in a sane
way in /proc/interrupts.
Signed-off-by: Thomas Gleixner
Cc: Linus Walleij
Cc: Lee Jones
Cc: linux-arm-ker...@lists.infradea
No more (ab)use in modules finally. Remove the export so there won't come
new ones.
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdesc.c |1 -
1 file changed, 1 deletion(-)
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -352,7 +352,6 @@ struct irq_desc *irq_to_desc(unsign
Let the core code do the fiddling with irq_desc.
Signed-off-by: Thomas Gleixner
Cc: Linus Walleij
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-g...@vger.kernel.org
---
drivers/pinctrl/nomadik/pinctrl-nomadik.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers
.
Retrieve a pointer to the affinity mask itself and use that. It's still
using an interface which is usually not for random drivers, but definitely
less hideous than the previous hack.
Signed-off-by: Thomas Gleixner
Cc: Tariq Toukan
Cc: "David S. Miller"
Cc: Jakub Kicin
means that checking the affinity mask itself does not really tell
about the actual target CPUs.
Signed-off-by: Thomas Gleixner
Cc: Saeed Mahameed
Cc: Leon Romanovsky
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: netdev@vger.kernel.org
Cc: linux-r...@vger.kernel.org
---
drivers/ne
.
Retrieve a pointer to the affinity mask itself and use that. It's still
using an interface which is usually not for random drivers, but definitely
less hideous than the previous hack.
Signed-off-by: Thomas Gleixner
---
drivers/net/ethernet/mellanox/mlx5/core/en.h |2 +-
drivers/net/eth
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
---
drivers/xen/events/events_base.c |6 --
1 file changed, 6 deletions(-)
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
Use the proper core function.
Signed-off-by: Thomas Gleixner
Cc: Jon Mason
Cc: Dave Jiang
Cc: Allen Hubbe
Cc: linux-...@googlegroups.com
---
drivers/ntb/msi.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/ntb/msi.c
+++ b/drivers/ntb/msi.c
@@ -282,15 +282,13
To prepare for interrupt spreading reduce the storage size of
irq_info::spurious_cnt to u8 so the required flag for the spreading logic
will not increase the storage size.
Protect the usage site against overruns.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano
Keep track of the assignments of event channels to CPUs and select the
online CPU with the least assigned channels in the affinity mask which is
handed to irq_chip::irq_set_affinity() from the core code.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano
irq().
This also prepares for proper interrupt spreading.
Signed-off-by: Thomas Gleixner
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
---
drivers/xen/events/events_base.c | 42 ++-
1 file changed, 28 inserti
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/kernel/smp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm/kernel/smp.c
+++ b
only counts interrupts which
originate from the graphics card.
To avoid atomics or heuristics of some sort make the counter field
'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and
postprocessing can easily deal with the occasional wraparound.
Signed-off-by: Thoma
Both the per cpu stats and the accumulated count are accessed lockless and
can be concurrently modified. That's intentional and the stats are a rough
estimate anyway. Annotate them with data_race().
Signed-off-by: Thomas Gleixner
---
kernel/irq/irqdesc.c |4 ++--
kernel/irq/proc.c|
Provide an accessor to the effective interrupt affinity mask. Going to be
used to replace open coded fiddling with the irq descriptor.
Signed-off-by: Thomas Gleixner
---
include/linux/irq.h |7 +++
1 file changed, 7 insertions(+)
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
A recent request to export kstat_irqs() pointed to a copy of the same in
the i915 code, which made me look for further usage of irq descriptors in
drivers.
The usage in drivers ranges from creative to broken in all colours.
irqdesc.h clearly says that this is core functionality and the fact C doe
Pavel,
On Sat, Dec 05 2020 at 21:40, Pavel Machek wrote:
> So... what kind of guarantees does this aim to provide / what tasks it
> is useful for?
>
> For real time response, we have other approaches.
Depends on your requirements. Some problems are actually better solved
with busy polling. See be
On Mon, Nov 23 2020 at 17:58, Alex Belits wrote:
> From: Yuri Norov
>
> For nohz_full CPUs the desirable behavior is to receive interrupts
> generated by tick_nohz_full_kick_cpu(). But for hard isolation it's
> obviously not desirable because it breaks isolation.
>
> This patch adds check for it.
Alex,
On Mon, Nov 23 2020 at 17:57, Alex Belits wrote:
> Kernel entry and exit functions for task isolation are added to context
> tracking and common entry points. Common handling of pending work on exit
> to userspace now processes isolation breaking, cleanup and start.
Again: You fail to expla
Alex,
On Mon, Nov 23 2020 at 17:56, Alex Belits wrote:
> .../admin-guide/kernel-parameters.txt | 6 +
> drivers/base/cpu.c| 23 +
> include/linux/hrtimer.h | 4 +
> include/linux/isolation.h | 326
> inclu
On Mon, Nov 23 2020 at 17:56, Alex Belits wrote:
> This function checks to see if a vmstat worker is not running,
> and the vmstat diffs don't require an update. The function is
> called from the task-isolation code to see if we need to
> actually do some work to quiet vmstat.
A changelog has to
Alex,
On Mon, Nov 23 2020 at 17:56, Alex Belits wrote:
why are you insisting on adding 'task_isolation: ' as prefix to every
single patch? That's wrong as I explained before.
The prefix denotes the affected subsystem and 'task_isolation' is _NOT_
a subsystem. It's the project name you are using
On Mon, Nov 09 2020 at 20:59, Ira Weiny wrote:
> On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Also, we can convert the new memcpy_*_page() calls to kmap_local() as well.
> [For now my patch just uses kmap_atomic().]
>
> I've not looked at all of the pa
Ira,
On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> From: Ira Weiny
>
> To correctly support the semantics of kmap() with Kernel protection keys
> (PKS), kmap() may be required to set the protections on multiple
> processors (globally). Enabling PKS globally can be very expensive
> depending o
On Thu, Oct 29 2020 at 11:19, Heiner Kallweit wrote:
> On 29.10.2020 10:42, Thomas Gleixner wrote:
> Correct, just that the legacy PCI interrupt scenario doesn't affect old
> systems/devices only. Users may run the system with nomsi for
> whatever reason and we need to be prepa
On Thu, Oct 29 2020 at 09:42, Heiner Kallweit wrote:
> On 29.10.2020 00:29, Jakub Kicinski wrote:
>> Other handles may take spin_locks, which will sleep on RT.
>>
>> I guess we may need to switch away from the _irqoff() variant for
>> drivers with IRQF_SHARED after all :(
>>
> Right. Unfortunatel
On Wed, Oct 28 2020 at 13:17, Heiner Kallweit wrote:
> On 28.10.2020 12:43, Serge Belyshev wrote:
>>> For several network drivers it was reported that using
>>> __napi_schedule_irqoff() is unsafe with forced threading. One way to
>>> fix this is switching back to __napi_schedule, but then we lose t
On Mon, Oct 26 2020 at 16:08, Jacob Keller wrote:
> On 10/26/2020 3:49 PM, Thomas Gleixner wrote:
>> On Mon, Oct 26 2020 at 18:22, Nitesh Narayan Lal wrote:
>>> I don't think there is currently a way to control the
>>> enablement/disablement of
>>> interru
On Tue, Oct 27 2020 at 08:47, Marcelo Tosatti wrote:
> On Mon, Oct 26, 2020 at 06:22:29PM -0400, Nitesh Narayan Lal wrote:
> However, if per-CPU interrupts are not disabled, then the (for example)
> network device is free to include the CPU in its list of destinations.
> Which would require one to
On Mon, Oct 26 2020 at 18:22, Nitesh Narayan Lal wrote:
> On 10/26/20 5:50 PM, Thomas Gleixner wrote:
>> But I still think that for curing that isolation stuff we want at least
>> some information from the driver. Alternative solution would be to grant
>> the allocation of
On Mon, Oct 26 2020 at 15:13, Jakub Kicinski wrote:
> On Mon, 26 Oct 2020 22:50:45 +0100 Thomas Gleixner wrote:
>> But I still think that for curing that isolation stuff we want at least
>> some information from the driver. Alternative solution would be to grant
>> the allocat
On Mon, Oct 26 2020 at 14:11, Jacob Keller wrote:
> On 10/26/2020 1:11 PM, Thomas Gleixner wrote:
>> On Mon, Oct 26 2020 at 12:21, Jacob Keller wrote:
>>> Are there drivers which use more than one interrupt per queue? I know
>>> drivers have multiple management in
On Mon, Oct 26 2020 at 12:21, Jacob Keller wrote:
> On 10/26/2020 12:00 PM, Thomas Gleixner wrote:
>> How does userspace know about the driver internals? Number of management
>> interrupts, optimal number of interrupts per queue?
>
> I guess this is the problem solved
On Mon, Oct 26 2020 at 14:30, Marcelo Tosatti wrote:
> On Fri, Oct 23, 2020 at 11:00:52PM +0200, Thomas Gleixner wrote:
>> So without information from the driver which tells what the best number
>> of interrupts is with a reduced number of CPUs, this cutoff will cause
>>
On Mon, Oct 26 2020 at 09:35, Nitesh Narayan Lal wrote:
> On 10/23/20 5:00 PM, Thomas Gleixner wrote:
>> An isolated setup, which I'm familiar with, has two housekeeping
>> CPUs. So far I restricted the number of network queues with a module
>> argument to two, whic
On Fri, Oct 23 2020 at 09:10, Nitesh Narayan Lal wrote:
> On 10/23/20 4:58 AM, Peter Zijlstra wrote:
>> On Thu, Oct 22, 2020 at 01:47:14PM -0400, Nitesh Narayan Lal wrote:
>> So shouldn't we then fix the drivers / interface first, to get rid of
>> this inconsistency?
>>
> Considering we agree that
On Thu, Oct 22 2020 at 09:28, Marcelo Tosatti wrote:
> On Wed, Oct 21, 2020 at 10:25:48PM +0200, Thomas Gleixner wrote:
>> The right answer to this is to utilize managed interrupts and have
>> according logic in your network driver to handle CPU hotplug. When a CPU
>> goes
On Wed, Oct 21 2020 at 17:02, Jakub Kicinski wrote:
> On Wed, 21 Oct 2020 22:25:48 +0200 Thomas Gleixner wrote:
>> The right answer to this is to utilize managed interrupts and have
>> according logic in your network driver to handle CPU hotplug. When a CPU
>> goes down, th
On Tue, Oct 20 2020 at 20:07, Thomas Gleixner wrote:
> On Tue, Oct 20 2020 at 12:18, Nitesh Narayan Lal wrote:
>> However, IMHO we would still need a logic to prevent the devices from
>> creating excess vectors.
>
> Managed interrupts are preventing exactly that by pinning
On Tue, Oct 20 2020 at 12:18, Nitesh Narayan Lal wrote:
> On 10/20/20 10:16 AM, Thomas Gleixner wrote:
>> With the above change this will result
>>
>>1 general interrupt which is free movable by user space
>>1 managed interrupts (possible affinity to all 16 C
On Mon, Sep 28 2020 at 14:35, Nitesh Narayan Lal wrote:
>
> + hk_cpus = housekeeping_num_online_cpus(HK_FLAG_MANAGED_IRQ);
> +
> + /*
> + * If we have isolated CPUs for use by real-time tasks, to keep the
> + * latency overhead to a minimum, device-specific IRQ vectors are moved
On Sun, Oct 18 2020 at 10:19, Jakub Kicinski wrote:
> On Sun, 18 Oct 2020 10:20:41 +0200 Heiner Kallweit wrote:
>> >> Otherwise a non-solution could be to make IRQ_FORCED_THREADING
>> >> configurable.
>> >
>> > I have to say I do not understand why we want to defer to a thread the
>> > hard IRQ
Jakub,
On Sat, Oct 17 2020 at 16:29, Jakub Kicinski wrote:
> On Sat, 17 Oct 2020 15:45:57 +0200 Heiner Kallweit wrote:
>> It turned out that this most of the time isn't safe in certain
>> configurations:
>> - if CONFIG_PREEMPT_RT is set
>> - if command line parameter threadirqs is set
>>
>> Havin
On Sat, Oct 17 2020 at 16:15, Alex Belits wrote:
> On Sat, 2020-10-17 at 18:08 +0200, Thomas Gleixner wrote:
>> On Sat, Oct 17 2020 at 01:08, Alex Belits wrote:
>> > I think that the goal of "finding source of disturbance" interface
>> > is
>> > diff
On Sat, Oct 17 2020 at 01:08, Alex Belits wrote:
> On Mon, 2020-10-05 at 14:52 -0400, Nitesh Narayan Lal wrote:
>> On 10/4/20 7:14 PM, Frederic Weisbecker wrote:
> I think that the goal of "finding source of disturbance" interface is
> different from what can be accomplished by tracing in two ways:
Andreas,
On Wed, Oct 14 2020 at 09:12, Andreas Meisinger wrote:
> Sorry about the wrong format/style of my last mail, hope I did get it
> right this time.
No problem. Yes this looks better. The only thing which could be
improved is that your mail client fails to add
In-Reply-To:
References:
On Thu, Oct 08 2020 at 17:46, Arnd Bergmann wrote:
> With Arm EBSA110 gone, nothing uses it any more, so the corresponding
> code and the Kconfig option can be removed.
Yay! It only took 11+ years to get rid of that.
Feel free to route it through your tree.
Acked-by: Thomas Gleixner
Andreas,
On Fri, Oct 09 2020 at 11:17, Andreas Meisinger wrote:
please do not top-post and trim your replies.
> Yet we do already have usecases where this can't be done. Additionally
> a lot of discussions at this topic are ongoing in 60802 profile
> creation too. Some of our usecases do requir
Vinicius,
On Fri, Oct 02 2020 at 12:01, Vinicius Costa Gomes wrote:
> I think that there's an underlying problem/limitation that is the cause
> of the issue (or at least a step in the right direction) you are trying
> to solve: the issue is that PTP clocks can't be used as hrtimers.
That's only a
On Thu, Oct 01 2020 at 22:51, Erez Geva wrote:
> - Add support for using a POSIX dynamic clock with
> Traffic control Earliest TxTime First (ETF) Qdisc.
> --- a/include/uapi/linux/net_tstamp.h
> +++ b/include/uapi/linux/net_tstamp.h
> @@ -167,6 +167,11 @@ enum txtime_flags {
> S
On Fri, Oct 02 2020 at 00:05, Thomas Gleixner wrote:
> On Thu, Oct 01 2020 at 22:51, Erez Geva wrote:
>
> same comments as for patch 1 apply.
>
>> Add kernel function to retrieve main clock oscillator state.
>
> The function you are adding is named adjtimex(). adjtimex(2
On Thu, Oct 01 2020 at 22:51, Erez Geva wrote:
> Add kernel functions to fetch a pointer to a POSIX dynamic clock
> using a user file description dynamic clock ID.
And how is that supposed to work. What are the lifetime rules?
> +struct posix_clock *posix_clock_get_clock(clockid_t id)
> +{
> +
On Thu, Oct 01 2020 at 22:51, Erez Geva wrote:
Issue? You again fail to decribe the problem.
> - Add new schedule function for Qdisc watchdog.
> The function avoids reprogram if watchdog already expire
> before new expire.
Why can't the existing function not be changed to do that?
>
On Thu, Oct 01 2020 at 22:51, Erez Geva wrote:
Fixes should be at the beginning of a patch series and not be hidden
somewhere in the middle.
>- As all parameters are unsigned.
This is not a sentence and this list style does not make that changelog
more readable.
>- If 'expires' is bigge
1 - 100 of 392 matches
Mail list logo
