Hi,
the following was in the PREEMPT_RT queue since last softirq rework. The
result is that timer wake ups (hrtimer, timer_list) happens in hardirq
processing them requires to wake ksoftirqd. ksoftirqd runs at SCHED_OTHER so it
will compete for resources with all other tasks in the system, potenti
og wouldn't suggest to the
> > casual reader that there might be a problem.
>
> Okay. I added a sentence. What about this rewording:
>
> Force-threaded interrupt handlers used to run with interrupts enabled,
> something which could lead to deadlocks in case a threade
ning in hard interrupt context (e.g.
> > > > > > > timer
> > > > > > > callbacks) and did not explicitly disable interrupts.
> > > > > > >
> > > > > > > This was specifically the case for serial drivers that take
explicitly disable interrupts.
> > > > > >
> > > > > > This was specifically the case for serial drivers that take the port
> > > > > > lock in their console write path as printk can be called from hard
> > > > > &g
rupts enabled,
something which could lead to deadlocks in case a threaded handler
shared a lock with code running in hard interrupt context (e.g. timer
callbacks) and did not explicitly disable interrupts.
This was specifically the case for serial drivers that take the port
lock in thei
Hello Sebastian,
On Mon, Mar 22, 2021 at 09:48:36PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-03-22 14:40:32 [+0100], Uwe Kleine-König wrote:
> > From a strictly logically point of view you indeed cannot. But if you go
> > to the street and say to people there that they can park their car
On 2021-03-22 14:40:32 [+0100], Uwe Kleine-König wrote:
> From a strictly logically point of view you indeed cannot. But if you go
> to the street and say to people there that they can park their car in
> this street free of charge between Monday and Friday, I expect that most
> of them will assume
On Mon, Mar 22, 2021 at 05:59:17PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-03-22 12:42:00 [-0400], Alan Stern wrote:
> > What happens on RT systems? Are they smart enough to avoid the whole
> > problem by enabling interrupts during _all_ callbacks?
>
> tl;dr: Yes.
>
> The referenced
On 2021-03-22 12:42:00 [-0400], Alan Stern wrote:
> What happens on RT systems? Are they smart enough to avoid the whole
> problem by enabling interrupts during _all_ callbacks?
tl;dr: Yes.
The referenced commit (id 81e2073c175b) disables interrupts only on !RT
configs so for RT everything rem
cks) and did not explicitly disable interrupts.
>
> Since commit 81e2073c175b ("genirq: Disable interrupts for force
> threaded handlers") interrupt handlers always run with interrupts
> disabled on non-RT so that drivers no longer need to do handle forced
> threading ("
> shared a lock with code running in hard interrupt context (e.g. timer
> > > > > callbacks) and did not explicitly disable interrupts.
> > > > >
> > > > > This was specifically the case for serial drivers that take the port
> > > > >
> > > > callbacks) and did not explicitly disable interrupts.
> > > >
> > > > This was specifically the case for serial drivers that take the port
> > > > lock in their console write path as printk can be called from hard
> > > > interrupt context also
ly the case for serial drivers that take the port
> > > lock in their console write path as printk can be called from hard
> > > interrupt context also with forced threading ("threadirqs").
> > >
> > > Since commit 81e2073c175b ("genirq: Disable
ared a lock with code running in hard interrupt context (e.g. timer
> > callbacks) and did not explicitly disable interrupts.
> >
> > This was specifically the case for serial drivers that take the port
> > lock in their console write path as printk can be called from hard
>
cks) and did not explicitly disable interrupts.
>
> This was specifically the case for serial drivers that take the port
> lock in their console write path as printk can be called from hard
> interrupt context also with forced threading ("threadirqs").
>
> Since commit 8
enirq: Disable interrupts for force
threaded handlers") interrupt handlers always run with interrupts
disabled on non-RT so that drivers no longer need to do handle forced
threading ("threadirqs").
Drop the now obsolete workaround added by commit a1227f3c1030 ("usb:
ehci: fix
enirq: Disable interrupts for force
threaded handlers") interrupt handlers always run with interrupts
disabled on non-RT so that drivers no longer need to do handle forced
threading ("threadirqs").
Drop the now obsolete workaround added by commit 63aea0dbab90 ("USB:
xhci: f
serial drivers that take the port
lock in their console write path as printk can be called from hard
interrupt context also with forced threading ("threadirqs").
Since commit 81e2073c175b ("genirq: Disable interrupts for force
threaded handlers") interrupt handlers always
ed in combination with forced threading.
There's no good way to deal with this properly, therefore we have to
remove flag IRQF_NO_THREAD. For fixing the original forced threading
issue switch to napi_schedule().
Fixes: 424a646e072a ("r8169: fix operation under forced interrupt threadin
ed in combination with forced threading.
There's no good way to deal with this properly, therefore we have to
remove flag IRQF_NO_THREAD. For fixing the original forced threading
issue switch to napi_schedule().
Fixes: 424a646e072a ("r8169: fix operation under forced interrupt threadin
ed in combination with forced threading.
There's no good way to deal with this properly, therefore we have to
remove flag IRQF_NO_THREAD. For fixing the original forced threading
issue switch to napi_schedule().
Fixes: 424a646e072a ("r8169: fix operation under forced interrupt threadin
ed in combination with forced threading.
There's no good way to deal with this properly, therefore we have to
remove flag IRQF_NO_THREAD. For fixing the original forced threading
issue switch to napi_schedule().
Fixes: 424a646e072a ("r8169: fix operation under forced interrupt threadin
From: Heiner Kallweit
[ Upstream commit 424a646e072a887aa87283b53aa6f8b19c2a7bef ]
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 the
benefit of the
From: Heiner Kallweit
[ Upstream commit 424a646e072a887aa87283b53aa6f8b19c2a7bef ]
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 the
benefit of the
From: Heiner Kallweit
[ Upstream commit 424a646e072a887aa87283b53aa6f8b19c2a7bef ]
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 the
benefit of the
From: Heiner Kallweit
[ Upstream commit 424a646e072a887aa87283b53aa6f8b19c2a7bef ]
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 the
benefit of the
interrupt threading on RT
Switch force_irqthreads from a boot time modifiable variable to a compile
time constant when CONFIG_PREEMPT_RT is enabled.
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
Signed-off-by: Thomas Gleixner
Link: https://lkml.kernel.org/r
Dear Rick,
It looks like your message is unrelated to the thread at hand.
Therefore, please start a new thread by *not* using the reply feature,
but create a new message in your mail program (MUA).
Please read some mailing list etiquettes on the Web like [1].
Kind regards,
Paul
[1]: htt
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Gleixner
commit d1f0301beef5efbfa1fe0f0edbea01863d5d upstream.
The support of force threading interrupts which are set up with both a
primary and a threaded handler wreckaged the
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Gleixner
commit d1f0301beef5efbfa1fe0f0edbea01863d5d upstream.
The support of force threading interrupts which are set up with both a
primary and a threaded handler wreckaged the
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Gleixner
commit d1f0301beef5efbfa1fe0f0edbea01863d5d upstream.
The support of force threading interrupts which are set up with both a
primary and a threaded handler wreckaged the
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Gleixner
commit d1f0301beef5efbfa1fe0f0edbea01863d5d upstream.
The support of force threading interrupts which are set up with both a
primary and a threaded handler wreckaged the
Hi Pavel,
Thank you for looking at this patch. BTW, the version 5 is out. The latest
thread is anchered here:
http://lkml.kernel.org/r/20180516024004.28977-1-pasha.tatas...@oracle.com
> ixgbe is network card, right? So ... it does not have any persistent
> state and no moving parts, and there's n
Hi!
> When system is rebooted, halted or kexeced device_shutdown() is
> called.
>
> This function shuts down every single device by calling either:
>
> dev->bus->shutdown(dev)
> dev->driver->shutdown(dev)
...
> Finally, with ixgbe_shutdown() it takes 0.37 for each device, but that ti
to disable
multi-threading as suggested by Greg Kroah-Hartman
v2 - v3
- Fixed warning from kbuild test.
- Moved device_lock/device_unlock inside device_shutdown_tree().
v1 - v2
- It turns out we cannot lock more than MAX_LOCK_DEPTH by a single
thread
When system is rebooted, halted or kexeced device_shutdown() is
called.
This function shuts down every single device by calling either:
dev->bus->shutdown(dev)
dev->driver->shutdown(dev)
Even on a machine with just a moderate amount of devices, device_shutdown()
may take multiple
Do all the necessary refactoring to prepare device_shutdown() logic to
be multi-threaded.
Which includes:
1. Change the direction of traversing the list instead of going backward,
we now go forward.
2. Children are shutdown recursively for each root device from bottom-up.
3. Functions that can be
Hi Greg,
> Can you refactor this to be at least 2 patches? One that moves code
> around to comon functions to make the second patch, that adds the new
> functionality, easier to review and understand?
Yes, I will split the patch into a two-three patches.
> And I echo the "don't use kerneldoc f
On Mon, May 14, 2018 at 03:42:54PM -0400, Pavel Tatashin wrote:
> When system is rebooted, halted or kexeced device_shutdown() is
> called.
>
> This function shuts down every single device by calling either:
>
> dev->bus->shutdown(dev)
> dev->driver->shutdown(dev)
>
> Even on a machi
Hi Andy,
Thank you for your comments. I will send an updated patch soon. My replies are
below:
On 05/14/2018 04:04 PM, Andy Shevchenko wrote:
> Can we still preserve an order here? (Yes, even if the entire list is
> not fully ordered)
> In the context I see it would go before netdevice.h.
Sure
On Mon, May 14, 2018 at 10:42 PM, Pavel Tatashin
wrote:
> #include
> #include
> #include
> +#include
Can we still preserve an order here? (Yes, even if the entire list is
not fully ordered)
In the context I see it would go before netdevice.h.
> +/**
> + * device_get_child_by_index - Retu
When system is rebooted, halted or kexeced device_shutdown() is
called.
This function shuts down every single device by calling either:
dev->bus->shutdown(dev)
dev->driver->shutdown(dev)
Even on a machine with just a moderate amount of devices, device_shutdown()
may take multiple
Changelog
v3 - v4
- Added device_shutdown_serial kernel parameter to disable
multi-threading as suggested by Greg Kroah-Hartman
v2 - v3
- Fixed warning from kbuild test.
- Moved device_lock/device_unlock inside device_shutdown_tree().
v1 - v2
- It turns
On 05/14/2018 11:03 AM, Greg KH wrote:
> On Mon, May 07, 2018 at 11:54:01AM -0400, Pavel Tatashin wrote:
>> Changelog
>> v2 - v3
>> - Fixed warning from kbuild test.
>> - Moved device_lock/device_unlock inside device_shutdown_tree().
>>
>> v1 - v2
>> - It turns out we cannot lock mor
On Mon, May 07, 2018 at 11:54:01AM -0400, Pavel Tatashin wrote:
> Changelog
> v2 - v3
> - Fixed warning from kbuild test.
> - Moved device_lock/device_unlock inside device_shutdown_tree().
>
> v1 - v2
> - It turns out we cannot lock more than MAX_LOCK_DEPTH by a single
>
ll the available CPU
resources.
Pavel Tatashin (1):
drivers core: multi-threading device shutdown
drivers/base/core.c | 275
1 file changed, 225 insertions(+), 50 deletions(-)
--
2.17.0
When system is rebooted, halted or kexeced device_shutdown() is
called.
This function shuts down every single device by calling either:
dev->bus->shutdown(dev)
dev->driver->shutdown(dev)
Even on a machine with just a moderate amount of devices, device_shutdown()
may take multiple
://github.com/0day-ci/linux/commits/Pavel-Tatashin/multi-threading-device-shutdown/20180506-035150
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/base/co
When system is rebooted, halted or kexeced device_shutdown() is
called.
This function shuts down every single device by calling either:
dev->bus->shutdown(dev)
dev->driver->shutdown(dev)
Even on a machine with just a moderate amount of devices, device_shutdown()
may take multiple
these functions for every single device but
only using one thread.
Since, nothing else is running on the machine by the device_shutdown()
s called, there is no reason not to utilize all the available CPU
resources.
Pavel Tatashin (1):
drivers core: multi-threading device shutdown
drivers/base/core.c
On Thu, May 3, 2018 at 1:54 AM Tobin C. Harding wrote:
> This code was a pleasure to read, super clean.
Hi Tobin,
Thank you very much for your review, I will address all of your comments in
the next revision.
BTW, I found a lock ordering issue in my work that that I will need to
fix:
In de
This code was a pleasure to read, super clean.
On Wed, May 02, 2018 at 11:59:31PM -0400, Pavel Tatashin wrote:
> When system is rebooted, halted or kexeced device_shutdown() is
> called.
>
> This function shuts down every single device by calling either:
> dev->bus->shutdown(dev)
> de
When system is rebooted, halted or kexeced device_shutdown() is
called.
This function shuts down every single device by calling either:
dev->bus->shutdown(dev)
dev->driver->shutdown(dev)
Even on a machine just with a moderate amount of devices, device_shutdown()
may take multiple
le CPU
resources.
Pavel Tatashin (2):
ixgbe: release lock for the duration of ixgbe_suspend_close()
drivers core: multi-threading device shutdown
drivers/base/core.c | 238 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 +-
2 files change
On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs wrote:
> Check if a task has existing children or co-threads and refuse to set
> the container ID if either are present. Failure to check this could
> permit games where a child scratches its parent's back to work around
> inheritance and double
Check if a task has existing children or co-threads and refuse to set
the container ID if either are present. Failure to check this could
permit games where a child scratches its parent's back to work around
inheritance and double-setting policy.
Signed-off-by: Richard Guy Briggs
---
kernel/aud
On Wed, Feb 07, 2018 at 12:18:44PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 19 Jan 2018 16:46:10 +0100
> Frederic Weisbecker escreveu:
>
> > As per Linus suggestion, this take doesn't limit the number of occurences
> > per jiffy anymore but instead defers a vector to workqueues as soon as
>
Em Fri, 19 Jan 2018 16:46:10 +0100
Frederic Weisbecker escreveu:
> As per Linus suggestion, this take doesn't limit the number of occurences
> per jiffy anymore but instead defers a vector to workqueues as soon as
> it gets re-enqueued on IRQ tail.
>
> No tunable here, so testing should be easie
On Wed, 2018-01-24 at 10:05 -0500, David Miller wrote:
> From: Paolo Abeni
> Date: Wed, 24 Jan 2018 15:54:05 +0100
>
> > Niklas suggested a possible relation with CONFIG_IRQ_TIME_ACCOUNTING=y
> > and indeed he was right.
> >
> > The patched kernel under test had CONFIG_IRQ_TIME_ACCOUNTING set, a
From: Paolo Abeni
Date: Wed, 24 Jan 2018 15:54:05 +0100
> Niklas suggested a possible relation with CONFIG_IRQ_TIME_ACCOUNTING=y
> and indeed he was right.
>
> The patched kernel under test had CONFIG_IRQ_TIME_ACCOUNTING set, and
> very little CPU time was accounted to the kworker:
>
> [2125 is
On Tue, 2018-01-23 at 09:42 -0800, Linus Torvalds wrote:
> On Tue, Jan 23, 2018 at 8:57 AM, Paolo Abeni wrote:
> >
> > > Or is it that the workqueue execution is simply not yielding for some
> > > reason?
> >
> > It's like that.
> >
> > I spent little time on it, so I haven't many data point. I
On Tue, Jan 23, 2018 at 12:32:13PM +, Dmitry Safonov wrote:
> On Tue, 2018-01-23 at 11:13 +0100, Paolo Abeni wrote:
> > Hi,
> >
> > On Fri, 2018-01-19 at 16:46 +0100, Frederic Weisbecker wrote:
> > > As per Linus suggestion, this take doesn't limit the number of
> > > occurences
> > > per jiff
2018-01-24 2:57 UTC+01:00, Frederic Weisbecker :
> On Tue, Jan 23, 2018 at 01:24:24PM -0500, David Miller wrote:
>> From: Linus Torvalds
>> Date: Tue, 23 Jan 2018 09:42:32 -0800
>>
>> > But I wonder if the test triggers the "lets run lots of workqueue
>> > threads", and then the single-threaded us
On Tue, Jan 23, 2018 at 01:24:24PM -0500, David Miller wrote:
> From: Linus Torvalds
> Date: Tue, 23 Jan 2018 09:42:32 -0800
>
> > But I wonder if the test triggers the "lets run lots of workqueue
> > threads", and then the single-threaded user space just gets blown out
> > of the water by many k
From: Linus Torvalds
Date: Tue, 23 Jan 2018 09:42:32 -0800
> But I wonder if the test triggers the "lets run lots of workqueue
> threads", and then the single-threaded user space just gets blown out
> of the water by many kernel threads. Each thread gets its own "fair"
> amount of CPU, but..
If
On Tue, 2018-01-23 at 09:42 -0800, Linus Torvalds wrote:
> On Tue, Jan 23, 2018 at 8:57 AM, Paolo Abeni wrote:
> >
> >> Or is it that the workqueue execution is simply not yielding for some
> >> reason?
> >
> > It's like that.
> >
> > I spent little time on it, so I haven't many data point. I'll t
On Tue, Jan 23, 2018 at 8:57 AM, Paolo Abeni wrote:
>
>> Or is it that the workqueue execution is simply not yielding for some
>> reason?
>
> It's like that.
>
> I spent little time on it, so I haven't many data point. I'll try to
> investigate the scenario later this week.
Hmm. workqueues seem t
On Tue, 2018-01-23 at 11:22 -0500, David Miller wrote:
> From: Paolo Abeni
> Date: Tue, 23 Jan 2018 11:13:52 +0100
>
> > Hi,
> >
> > On Fri, 2018-01-19 at 16:46 +0100, Frederic Weisbecker wrote:
> >> As per Linus suggestion, this take doesn't limit the number of occurences
> >> per jiffy anymore
From: Paolo Abeni
Date: Tue, 23 Jan 2018 11:13:52 +0100
> Hi,
>
> On Fri, 2018-01-19 at 16:46 +0100, Frederic Weisbecker wrote:
>> As per Linus suggestion, this take doesn't limit the number of occurences
>> per jiffy anymore but instead defers a vector to workqueues as soon as
>> it gets re-enq
On Tue, 2018-01-23 at 11:13 +0100, Paolo Abeni wrote:
> Hi,
>
> On Fri, 2018-01-19 at 16:46 +0100, Frederic Weisbecker wrote:
> > As per Linus suggestion, this take doesn't limit the number of
> > occurences
> > per jiffy anymore but instead defers a vector to workqueues as soon
> > as
> > it gets
Hi,
On Fri, 2018-01-19 at 16:46 +0100, Frederic Weisbecker wrote:
> As per Linus suggestion, this take doesn't limit the number of occurences
> per jiffy anymore but instead defers a vector to workqueues as soon as
> it gets re-enqueued on IRQ tail.
>
> No tunable here, so testing should be easie
Em Fri, 19 Jan 2018 16:46:10 +0100
Frederic Weisbecker escreveu:
> As per Linus suggestion, this take doesn't limit the number of occurences
> per jiffy anymore but instead defers a vector to workqueues as soon as
> it gets re-enqueued on IRQ tail.
>
> No tunable here, so testing should be easie
As per Linus suggestion, this take doesn't limit the number of occurences
per jiffy anymore but instead defers a vector to workqueues as soon as
it gets re-enqueued on IRQ tail.
No tunable here, so testing should be easier.
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
On Thu, 2018-01-18 at 05:09 +0100, Frederic Weisbecker wrote:
> On Wed, Jan 17, 2018 at 07:09:39PM -0800, Linus Torvalds wrote:
> > It should never trigger under any normal load, but I think it
> > *should*
> > trigger under the load that the networking people worry about. If
> > you
> > get a floo
On Wed, Jan 17, 2018 at 07:09:39PM -0800, Linus Torvalds wrote:
> On Wed, Jan 17, 2018 at 6:55 PM, Frederic Weisbecker
> wrote:
> >> I thought you were going to actally account for time, but I don't
> >> think you ended up doing that.
> >
> > I did in the first version but then I thought you sugge
On Wed, Jan 17, 2018 at 6:55 PM, Frederic Weisbecker
wrote:
>> I thought you were going to actally account for time, but I don't
>> think you ended up doing that.
>
> I did in the first version but then I thought you suggested that count per
> jiffy. I probably misunderstood :)
Oh, miscommunicati
On Wed, Jan 17, 2018 at 03:56:43PM -0800, Linus Torvalds wrote:
> On Wed, Jan 17, 2018 at 10:07 AM, Frederic Weisbecker
> wrote:
> >
> > I see, so you may want to test (possibly much) higher values of
> > MAX_SOFTIRQ_RESTART,
> > such as 50 or 100.
>
> I suspect the "number of softiqs per jiffy"
On Wed, Jan 17, 2018 at 10:07 AM, Frederic Weisbecker
wrote:
>
> I see, so you may want to test (possibly much) higher values of
> MAX_SOFTIRQ_RESTART,
> such as 50 or 100.
I suspect the "number of softiqs per jiffy" is hardly interesting at all.
We used to allow up to 2mS or ten iterations per
Hi Mauro,
On Wed, Jan 17, 2018 at 02:56:20PM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 16 Jan 2018 05:40:35 +0100
> Frederic Weisbecker escreveu:
>
> > So this set is in a testable state. I addressed preliminary reviews from
> > Eric Dumazet, Paolo Abeni and Linus.
> >
> > You may want to p
Em Tue, 16 Jan 2018 05:40:35 +0100
Frederic Weisbecker escreveu:
> So this set is in a testable state. I addressed preliminary reviews from
> Eric Dumazet, Paolo Abeni and Linus.
>
> You may want to play with MAX_SOFTIRQ_RESTART value, which is now the
> number of calls allowed for a vector in a
So this set is in a testable state. I addressed preliminary reviews from
Eric Dumazet, Paolo Abeni and Linus.
You may want to play with MAX_SOFTIRQ_RESTART value, which is now the
number of calls allowed for a vector in a jiffy frame before it gets
queued to the workqueue. I set it to the arbitrar
So this is a first shot to implement what Linus suggested.
To summarize: when a softirq vector is stormed and needs more time than
what IRQ tail can offer, the whole softirq processing is offloaded to
ksoftirqd. But this has an impact on other softirq vectors that are
then subject to scheduler late
load/unload, and
2. sysfs/proc_fs file accesses, and
3. etc.
Actually, performing such stuffs once or single-threaded won't prove
quality status to us, multi-threading testability is needed for these
validations.
This patch adds a test facility so that validators can use it to
launch multi-thre
On Fri, 25 Aug 2017, Thomas Gleixner wrote:
> On Fri, 25 Aug 2017, Vineet Gupta wrote:
> > On 06/15/2017 01:43 AM, Noam Camus wrote:
> > > From: Noam Camus
> > >
> > > Working with NPS400 we noticed that there is a possibility of L1
> > > interrupt nesting that may run out kernel stack.
> > > Th
>
> ARC ipi, timer, perf interrupts happen to use request_percpu_irq() which
> doesn't take flags and doesn't seem to force NO_THREAD internally either. Does
> that mean we first need to convert all of these sites to
> __request_percpu_irq(.. NO_THREAD ...) or is there a better way of doing this
> !
PER CPU interrupts are excluded from force threading automatically.
Thanks,
tglx
+CC Peter, Tglx, Steven
On 06/15/2017 01:43 AM, Noam Camus wrote:
From: Noam Camus
Working with NPS400 we noticed that there is a possibility of L1
interrupt nesting that may run out kernel stack.
The scenario include serving invoke_softirqs() from irq_exit()
and once local_irq_enable() called
From: Noam Camus
Working with NPS400 we noticed that there is a possibility of L1
interrupt nesting that may run out kernel stack.
The scenario include serving invoke_softirqs() from irq_exit()
and once local_irq_enable() called can hit another one before we
managed to restore last one and pop so
From: Noam Camus
Working with NPS400 we noticed that there is a possibility of L1
interrupt nesting that may run out kernel stack.
The scenario include serving invoke_softirqs() from irq_exit()
and once local_irq_enable() called can hit another one before we
managed to restore last one and pop so
From: Noam Camus
Working with NPS400 we noticed that there is a possibility of L1
interrupt nesting that may run out kernel stack.
The scenario include serving invoke_softirqs() from irq_exit()
and once local_irq_enable() called can hit another one before we
managed to restore last one and pop so
From: Jonas Pfeil
Add support for threaded fragment shaders. The validation code checks
for thread switch signals and ensures that the registers of the other
thread are not touched, and that our clamps are not live across thread
switches. It also checks that the threading and branching
best model.
>
> Exactly, I think we are outright discarding using workqueues even
> without investigating it in detail even though it would be a cleaner
> implementation using a common framework and thereby more chances of
> an acceptable solution for upstream.
I'm not sug
"Michael Rapoport" writes:
...
>
> Well, Elvis is a _theoretical_ example that showed that I/O scheduling in
> the vhost improves performance.
> I'm not saying we should take Evlis and try to squeeze it into the vhost,
> I just want to say that we cannot switch vhost to use workqueues if it
> c
.
> >>
> >> Example:
> >> vhost creates a worker thread when invoked for a kvm guest. Since,
> >> the guest is a normal process, the kernel thread servicing it should
be
> >> attached to the vm process' cgroups.
> >
> > I did some
; From: Thomas Gleixner
>
> Force threading of interrupts does not deal with interrupts which are
> requested with a primary and a threaded handler. The current policy is
> to leave them alone and let the primary handler run in interrupt
> context, but we set the ONESHOT flag for those interru
This series introduces support for the multi-core & multi-threading
capabilities of the I6400. That is, it introduces support for MIPSr6
Virtual Processors & enables CPS SMP for MIPSr6.
Based atop v4.5-rc2.
Markos Chandras (3):
MIPS: traps: Make sure secondary cores have a sane ebase
On Thu, Dec 03, 2015 at 11:33:14PM +0100, Thomas Gleixner wrote:
> Yunhong,
>
> On Thu, 3 Dec 2015, Yunhong Jiang wrote:
>
> > Hi, Thomas
> > On Commit 2a1d3ab8986d1b2 ("genirq: Handle force threading of irqs
> > with primary and thre
Yunhong,
On Thu, 3 Dec 2015, Yunhong Jiang wrote:
> Hi, Thomas
> On Commit 2a1d3ab8986d1b2 ("genirq: Handle force threading of irqs
> with primary and thread handler"), even if the caller of
> request_threaded_irq() provides a primary handler, that primary handler
Hi, Thomas
On Commit 2a1d3ab8986d1b2 ("genirq: Handle force threading of irqs
with primary and thread handler"), even if the caller of
request_threaded_irq() provides a primary handler, that primary handler will
be invoked in thread context. This may cause some latency issu
Hi,
Thomas Gleixner writes:
> On Tue, 6 Oct 2015, Felipe Balbi wrote:
>> this commit causes a performance regression for the USB driver on
>> several platforms (anybody using drivers/usb/dwc3, basically).
>>
>> Here's the USB throughput with linux-next in 3 different scenarios:
>>
>> 1) Linux
On Tue, 6 Oct 2015, Felipe Balbi wrote:
> this commit causes a performance regression for the USB driver on
> several platforms (anybody using drivers/usb/dwc3, basically).
>
> Here's the USB throughput with linux-next in 3 different scenarios:
>
> 1) Linux next without threadirqs cmdline
>
>
1 - 100 of 253 matches
Mail list logo
