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 w
interrupt 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 +++
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
- Renam
Haris
On 04/12/2018 10:00 AM, 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
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 M
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 avo
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: boris
interrupt 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
storing lists of expired 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 loo
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). Wil
I'm 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.
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
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
*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
know
,2/2]
-- Haris
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 i
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, Sebastia
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() fun
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
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/9882
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
t, perhaps)?
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_t
storing lists of expired 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 loo
interrupt 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 --gi
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 (ktimersoft
mers.
https://github.com/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
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 case
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 middle
+ base->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, Har
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-wa
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
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 9*s
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 corr
35 matches
Mail list logo
