Sounds good. I'll keep an eye out for your patch set and try it on my
boards as well. CC me if you can.
-- Haris
On 07/13/2018 07:01 AM, Anna-Maria Gleixner wrote:
Hi Haris,
On Thu, 28 Jun 2018, Haris Okanovic wrote:
Collect expired timers in interrupt context to avoid overhead of waking
Sounds good. I'll keep an eye out for your patch set and try it on my
boards as well. CC me if you can.
-- Haris
On 07/13/2018 07:01 AM, Anna-Maria Gleixner wrote:
Hi Haris,
On Thu, 28 Jun 2018, Haris Okanovic wrote:
Collect expired timers in interrupt context to avoid overhead of waking
time instead.
Signed-off-by: Haris Okanovic
---
[PATCH v3]
- Split block_softirq into separate commit
[PATCH v4]
- Rebase onto v4.14.20-rt17
[PATCH v5]
no change
https://github.com/harisokanovic/linux/tree/dev/hokanovi/timer-peek-v7
---
kernel/time/timer.c | 21 +++--
1 file
time instead.
Signed-off-by: Haris Okanovic
---
[PATCH v3]
- Split block_softirq into separate commit
[PATCH v4]
- Rebase onto v4.14.20-rt17
[PATCH v5]
no change
https://github.com/harisokanovic/linux/tree/dev/hokanovi/timer-peek-v7
---
kernel/time/timer.c | 21 +++--
1 file
Signed-off-by: Haris Okanovic
---
[PATCH v2] Applied Thomas Gleixner's suggestions:
- Fix expired_count race
- Remove unneeded base->clk lookahead
- Return expired_count in collect_expired_timers()
- Add block_softirq
- Rebase to v4.11.8-rt5
[PATCH v3]
- Fix cosmetic issues
- Rename &qu
Signed-off-by: Haris Okanovic
---
[PATCH v2] Applied Thomas Gleixner's suggestions:
- Fix expired_count race
- Remove unneeded base->clk lookahead
- Return expired_count in collect_expired_timers()
- Add block_softirq
- Rebase to v4.11.8-rt5
[PATCH v3]
- Fix cosmetic issues
- Rename &qu
, Haris Okanovic wrote:
Hi Mike,
I haven't tested the patch with wireshark until now. My system also
hangs shortly after it starts. I'm pretty sure I hit workqueues in my
earlier tests via the block driver, but it's clearly not whatever
wireshark is using. I'll look at it and try to post a fix
, Haris Okanovic wrote:
Hi Mike,
I haven't tested the patch with wireshark until now. My system also
hangs shortly after it starts. I'm pretty sure I hit workqueues in my
earlier tests via the block driver, but it's clearly not whatever
wireshark is using. I'll look at it and try to post a fix
Hi Daniel,
I didn't have time to look at it yet, aside from confirming Mike's issue
reproduces on my machine. It's still on my backlog to investigate.
-- Haris
On 06/19/2018 07:43 AM, Daniel Bristot de Oliveira wrote:
On 04/12/2018 05:00 PM, Haris Okanovic wrote:
Hi Mike,
I haven't
Hi Daniel,
I didn't have time to look at it yet, aside from confirming Mike's issue
reproduces on my machine. It's still on my backlog to investigate.
-- Haris
On 06/19/2018 07:43 AM, Daniel Bristot de Oliveira wrote:
On 04/12/2018 05:00 PM, Haris Okanovic wrote:
Hi Mike,
I haven't
Hi Mike,
I haven't tested the patch with wireshark until now. My system also
hangs shortly after it starts. I'm pretty sure I hit workqueues in my
earlier tests via the block driver, but it's clearly not whatever
wireshark is using. I'll look at it and try to post a fix. CCing the
list to
Hi Mike,
I haven't tested the patch with wireshark until now. My system also
hangs shortly after it starts. I'm pretty sure I hit workqueues in my
earlier tests via the block driver, but it's clearly not whatever
wireshark is using. I'll look at it and try to post a fix. CCing the
list to
On 03/23/2018 09:58 AM, Naga Sureshkumar Relli wrote:
Hi Miquel,
Thanks for reviewing the patch.
Please see my comments inline.
-Original Message-
From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
Sent: Tuesday, March 20, 2018 4:08 AM
To: nagasureshkumarre...@gmail.com
Cc:
On 03/23/2018 09:58 AM, Naga Sureshkumar Relli wrote:
Hi Miquel,
Thanks for reviewing the patch.
Please see my comments inline.
-Original Message-
From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
Sent: Tuesday, March 20, 2018 4:08 AM
To: nagasureshkumarre...@gmail.com
Cc:
time instead.
Signed-off-by: Haris Okanovic <haris.okano...@ni.com>
---
[PATCH v3]
- Split block_softirq into separate commit
[PATCH v4]
- Rebase onto v4.14.20-rt17
https://github.com/harisokanovic/linux/tree/dev/hokanovi/timer-peek-v6
---
kernel/time/timer.c | 21 +++--
time instead.
Signed-off-by: Haris Okanovic
---
[PATCH v3]
- Split block_softirq into separate commit
[PATCH v4]
- Rebase onto v4.14.20-rt17
https://github.com/harisokanovic/linux/tree/dev/hokanovi/timer-peek-v6
---
kernel/time/timer.c | 21 +++--
1 file changed, 19 insertions
timers in timer_base,
updated on each tick. Any addition to the lists wakes ktimersoftd
(softirq) to process those timers.
Signed-off-by: Haris Okanovic <haris.okano...@ni.com>
---
[PATCH v2] Applied Thomas Gleixner's suggestions:
- Fix expired_count race
- Remove unneeded base->clk
timers in timer_base,
updated on each tick. Any addition to the lists wakes ktimersoftd
(softirq) to process those timers.
Signed-off-by: Haris Okanovic
---
[PATCH v2] Applied Thomas Gleixner's suggestions:
- Fix expired_count race
- Remove unneeded base->clk lookahead
- Return expired_co
On 03/02/2018 10:39 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-02 10:29:56 [-0600], Haris Okanovic wrote:
Could please point me to the code/patches or something?
I rebase onto v4.14.20-rt17, running some sanity test before reposting to ml
(cyclictest & Anna's timertest). Will pos
On 03/02/2018 10:39 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-02 10:29:56 [-0600], Haris Okanovic wrote:
Could please point me to the code/patches or something?
I rebase onto v4.14.20-rt17, running some sanity test before reposting to ml
(cyclictest & Anna's timertest). Will pos
fine leaving it out of 4.9.
-- Haris
On 03/02/2018 08:52 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-01 12:37:49 [-0600], Haris Okanovic wrote:
It was added back into 4.9 at some point after v4.9.30-rt20. I see an older
version in v4.9.68-rt60, for example, hence my original email. It was
dro
fine leaving it out of 4.9.
-- Haris
On 03/02/2018 08:52 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-01 12:37:49 [-0600], Haris Okanovic wrote:
It was added back into 4.9 at some point after v4.9.30-rt20. I see an older
version in v4.9.68-rt60, for example, hence my original email. It was
dro
On 03/01/2018 10:47 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-01 09:49:59 [-0600], Haris Okanovic wrote:
*bump* Has anyone looked into this?
I'm lost.
It entered the kernel in v4.9.9-rt6 and left in v4.9.30-rt20 once we
figured out that there is something wrong with it.
It was added
On 03/01/2018 10:47 AM, Sebastian Andrzej Siewior wrote:
On 2018-03-01 09:49:59 [-0600], Haris Okanovic wrote:
*bump* Has anyone looked into this?
I'm lost.
It entered the kernel in v4.9.9-rt6 and left in v4.9.30-rt20 once we
figured out that there is something wrong with it.
It was added
No problem. I know you've been busy recently. I'll post an update.
-- Haris
On 03/01/2018 09:54 AM, Thomas Gleixner wrote:
On Thu, 1 Mar 2018, Haris Okanovic wrote:
*bump* Has anyone looked into this?
I have, but it's still in my melted spectrum induced backlog and it does
not apply
No problem. I know you've been busy recently. I'll post an update.
-- Haris
On 03/01/2018 09:54 AM, Thomas Gleixner wrote:
On Thu, 1 Mar 2018, Haris Okanovic wrote:
*bump* Has anyone looked into this?
I have, but it's still in my melted spectrum induced backlog and it does
not apply
*bump* Has anyone looked into this?
On 01/05/2018 01:37 PM, Haris Okanovic wrote:
It looks like an old version of this patch is included in v4.9*-rt*
kernels -- E.g. commit 032f93ca in v4.9.68-rt60. There's nothing
functionally wrong with the included version to the best of my
knowledge
*bump* Has anyone looked into this?
On 01/05/2018 01:37 PM, Haris Okanovic wrote:
It looks like an old version of this patch is included in v4.9*-rt*
kernels -- E.g. commit 032f93ca in v4.9.68-rt60. There's nothing
functionally wrong with the included version to the best of my
knowledge
On 08/03/2017 04:06 PM, Haris Okanovic wrote:
This change avoid 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
On 08/03/2017 04:06 PM, Haris Okanovic wrote:
This change avoid 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
Neither wmb() nor mb() have any effect when substituted for
ioread8(iobase + TPM_ACCESS(0)) in tpm_tis_flush(). I still see 300 -
400 us spikes in cyclictest invoking my TPM chip's RNG.
-- Haris
On 08/17/2017 12:17 PM, Jason Gunthorpe wrote:
On Thu, Aug 17, 2017 at 12:38:07PM +0200,
Neither wmb() nor mb() have any effect when substituted for
ioread8(iobase + TPM_ACCESS(0)) in tpm_tis_flush(). I still see 300 -
400 us spikes in cyclictest invoking my TPM chip's RNG.
-- Haris
On 08/17/2017 12:17 PM, Jason Gunthorpe wrote:
On Thu, Aug 17, 2017 at 12:38:07PM +0200,
*()) that follows.
The enclosed change appears to fix this issue: read the TPM chip's
access register (status code) after every iowrite*() operation to
amortize the cost of flushing data to chip across multiple instructions.
Signed-off-by: Haris Okanovic <haris.okano...@ni.com>
---
[PATCH v
*()) that follows.
The enclosed change appears to fix this issue: read the TPM chip's
access register (status code) after every iowrite*() operation to
amortize the cost of flushing data to chip across multiple instructions.
Signed-off-by: Haris Okanovic
---
[PATCH v2] Add tpm_tis_flush() function
On 08/15/2017 01:11 AM, Alexander Stein wrote:
On Monday 14 August 2017 17:53:47, Haris Okanovic wrote:
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -52,6 +52,22 @@ static inline struct tpm_tis_tcg_phy
*to_tpm_tis_tcg_phy(struct tpm_tis_data *da return container_of
On 08/15/2017 01:11 AM, Alexander Stein wrote:
On Monday 14 August 2017 17:53:47, Haris Okanovic wrote:
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -52,6 +52,22 @@ static inline struct tpm_tis_tcg_phy
*to_tpm_tis_tcg_phy(struct tpm_tis_data *da return container_of
On 08/08/2017 04:58 PM, Jarkko Sakkinen wrote:
On Mon, Aug 07, 2017 at 09:59:35AM -0500, Julia Cartwright wrote:
On Fri, Aug 04, 2017 at 04:56:51PM -0500, Haris Okanovic wrote:
I have a latency issue using a SPI-based TPM chip with tpm_tis driver
from non-rt usermode application, which
On 08/08/2017 04:58 PM, Jarkko Sakkinen wrote:
On Mon, Aug 07, 2017 at 09:59:35AM -0500, Julia Cartwright wrote:
On Fri, Aug 04, 2017 at 04:56:51PM -0500, Haris Okanovic wrote:
I have a latency issue using a SPI-based TPM chip with tpm_tis driver
from non-rt usermode application, which
*()) that follows.
The enclosed change appears to fix this issue: read the TPM chip's
access register (status code) after every iowrite*() operation to
amortize the cost of flushing data to chip across multiple instructions.
Signed-off-by: Haris Okanovic <haris.okano...@ni.com>
---
*()) that follows.
The enclosed change appears to fix this issue: read the TPM chip's
access register (status code) after every iowrite*() operation to
amortize the cost of flushing data to chip across multiple instructions.
Signed-off-by: Haris Okanovic
---
https://patchwork.kernel.org/patch/9882119/
https
On 08/07/2017 09:59 AM, Julia Cartwright wrote:
On Fri, Aug 04, 2017 at 04:56:51PM -0500, Haris Okanovic wrote:
I have a latency issue using a SPI-based TPM chip with tpm_tis driver
from non-rt usermode application, which induces ~400 us latency spikes
in cyclictest (Intel Atom E3940 system
On 08/07/2017 09:59 AM, Julia Cartwright wrote:
On Fri, Aug 04, 2017 at 04:56:51PM -0500, Haris Okanovic wrote:
I have a latency issue using a SPI-based TPM chip with tpm_tis driver
from non-rt usermode application, which induces ~400 us latency spikes
in cyclictest (Intel Atom E3940 system
)?
Thanks,
Haris Okanovic
https://github.com/harisokanovic/linux/tree/dev/hokanovi/tpm-latency-spike-fix-rfc
---
drivers/char/tpm/tpm_tis.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index
)?
Thanks,
Haris Okanovic
https://github.com/harisokanovic/linux/tree/dev/hokanovi/tpm-latency-spike-fix-rfc
---
drivers/char/tpm/tpm_tis.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index
timers in timer_base,
updated on each tick. Any addition to the lists wakes ktimersoftd
(softirq) to process those timers.
Signed-off-by: Haris Okanovic <haris.okano...@ni.com>
---
[PATCH v2] Applied Thomas Gleixner's suggestions:
- Fix expired_count race
- Remove unneeded base->clk
timers in timer_base,
updated on each tick. Any addition to the lists wakes ktimersoftd
(softirq) to process those timers.
Signed-off-by: Haris Okanovic
---
[PATCH v2] Applied Thomas Gleixner's suggestions:
- Fix expired_count race
- Remove unneeded base->clk lookahead
- Return expired_co
time instead.
Signed-off-by: Haris Okanovic <haris.okano...@ni.com>
---
[PATCH v3]
- Split block_softirq into separate commit
https://github.com/harisokanovic/linux/tree/dev/hokanovi/timer-peek-v5
---
kernel/time/timer.c | 21 +++--
1 file changed, 19 insertions(+), 2 del
time instead.
Signed-off-by: Haris Okanovic
---
[PATCH v3]
- Split block_softirq into separate commit
https://github.com/harisokanovic/linux/tree/dev/hokanovi/timer-peek-v5
---
kernel/time/timer.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/kernel
Thomas,
Apologies on the late response. I've been busy last few weeks.
On 07/18/2017 04:33 PM, Thomas Gleixner wrote:
On Mon, 17 Jul 2017, Haris Okanovic wrote:
We recently upgraded from 4.1 to 4.6 and noticed a minor latency
regression caused by an additional thread wakeup (ktimersoftd
Thomas,
Apologies on the late response. I've been busy last few weeks.
On 07/18/2017 04:33 PM, Thomas Gleixner wrote:
On Mon, 17 Jul 2017, Haris Okanovic wrote:
We recently upgraded from 4.1 to 4.6 and noticed a minor latency
regression caused by an additional thread wakeup (ktimersoftd
/harisokanovic/linux/tree/dev/hokanovi/timer-peek-v4
Signed-off-by: Haris Okanovic <haris.okano...@ni.com>
---
[PATCH v2] Applied Thomas Gleixner's suggestions:
- Fix expired_count race
- Remove unneeded base->clk lookahead
- Return expired_count in collect_expired_timers()
- Add bloc
/harisokanovic/linux/tree/dev/hokanovi/timer-peek-v4
Signed-off-by: Haris Okanovic
---
[PATCH v2] Applied Thomas Gleixner's suggestions:
- Fix expired_count race
- Remove unneeded base->clk lookahead
- Return expired_count in collect_expired_timers()
- Add block_softirq
- Rebase to v4.11.8-
On 06/04/2017 09:17 AM, Thomas Gleixner wrote:
On Fri, 2 Jun 2017, Haris Okanovic wrote:
On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
static void expire_timers(struct timer_base *base)
{
struct hlist_head *head;
+ int expCount = base->expired_count;
No camel c
On 06/04/2017 09:17 AM, Thomas Gleixner wrote:
On Fri, 2 Jun 2017, Haris Okanovic wrote:
On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
static void expire_timers(struct timer_base *base)
{
struct hlist_head *head;
+ int expCount = base->expired_count;
No camel c
On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
On Fri, 26 May 2017, Haris Okanovic wrote:
Oh crap. I think I see the problem. I decrement expired_count before
processing the list. Dropping the lock permits another run of
tick_find_expired()->find_expired_timers() in the mid
On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
On Fri, 26 May 2017, Haris Okanovic wrote:
Oh crap. I think I see the problem. I decrement expired_count before
processing the list. Dropping the lock permits another run of
tick_find_expired()->find_expired_timers() in the mid
t;expired_count;
+ while (expCount--) {
+ head = base->expired_lists + expCount;
__expire_timers(base, head);
}
base->expired_count = 0;
}
Thanks,
Haris
On 05/26/2017 02:49 PM, Thomas Gleixner wrote:
On Fri, 26 May 2017, Haris Okanovi
t;expired_count;
+ while (expCount--) {
+ head = base->expired_lists + expCount;
__expire_timers(base, head);
}
base->expired_count = 0;
}
Thanks,
Haris
On 05/26/2017 02:49 PM, Thomas Gleixner wrote:
On Fri, 26 May 2017, Haris Okanovi
Anna-Maria,
Look-ahead is implemented by tick_find_expired() and expiry by
__run_timers(), both of which hold timer_base::lock (raw spin lock)
while running. Those two routines shouldn't be able to run
simultaneously on the same timer_base. Are you sure the race isn't in
another code path?
Anna-Maria,
Look-ahead is implemented by tick_find_expired() and expiry by
__run_timers(), both of which hold timer_base::lock (raw spin lock)
while running. Those two routines shouldn't be able to run
simultaneously on the same timer_base. Are you sure the race isn't in
another code path?
On 02/03/2017 10:51 AM, Sebastian Andrzej Siewior wrote:
On 2016-12-13 15:44:05 [-0600], Haris Okanovic wrote:
Changed the way timers are collected per Julia and Thomas'
recommendation: Expired timers are now collected in interrupt context
and fired in ktimersoftd to avoid double-walk
On 02/03/2017 10:51 AM, Sebastian Andrzej Siewior wrote:
On 2016-12-13 15:44:05 [-0600], Haris Okanovic wrote:
Changed the way timers are collected per Julia and Thomas'
recommendation: Expired timers are now collected in interrupt context
and fired in ktimersoftd to avoid double-walk
on each tick. Any addition to the lists wakes ktimersoftd
(softirq) to process those timers.
Please refer to the following RFC threads for more details:
https://www.spinics.net/lists/linux-rt-users/msg16095.html
https://www.spinics.net/lists/linux-rt-users/msg16113.html
Signed-off-by: Haris Okanovic
on each tick. Any addition to the lists wakes ktimersoftd
(softirq) to process those timers.
Please refer to the following RFC threads for more details:
https://www.spinics.net/lists/linux-rt-users/msg16095.html
https://www.spinics.net/lists/linux-rt-users/msg16113.html
Signed-off-by: Haris Okanovic
On 12/23/2016 11:28 AM, Sebastian Andrzej Siewior wrote:
On 2016-12-13 15:44:05 [-0600], Haris Okanovic wrote:
Changed the way timers are collected per Julia and Thomas'
I can only see Julia's response to the initial thread.
I should have been more clear. Thomas commented on irc
On 12/23/2016 11:28 AM, Sebastian Andrzej Siewior wrote:
On 2016-12-13 15:44:05 [-0600], Haris Okanovic wrote:
Changed the way timers are collected per Julia and Thomas'
I can only see Julia's response to the initial thread.
I should have been more clear. Thomas commented on irc
Changed the way timers are collected per Julia and Thomas'
recommendation: Expired timers are now collected in interrupt context
and fired in ktimersoftd to avoid double-walk of `pending_map`.
This is implemented by storing lists of expired timers in timer_base,
which carries a memory overhead
Changed the way timers are collected per Julia and Thomas'
recommendation: Expired timers are now collected in interrupt context
and fired in ktimersoftd to avoid double-walk of `pending_map`.
This is implemented by storing lists of expired timers in timer_base,
which carries a memory overhead
Implement polling on procfs' "interrupts" file which observes changes
to IRQ action handlers. A poll()ed file descriptor will be flagged
EPOLLIN each time an action handler is registered or unregistered.
Use case:
Designing a thread priority policy on a system is critically important
for the
Implement polling on procfs' "interrupts" file which observes changes
to IRQ action handlers. A poll()ed file descriptor will be flagged
EPOLLIN each time an action handler is registered or unregistered.
Use case:
Designing a thread priority policy on a system is critically important
for the
70 matches
Mail list logo
