From: Sven-Thorsten Dietrich <thebigcorporation@gmail.com>
To: Peter LaDow <pladow@gmail.com>
Cc: Peter LaDow <petela@gocougs.wsu.edu>,
"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Subject: Re: Interrupt Bottom Half Scheduling
Date: Mon, 14 Feb 2011 16:50:18 -0800 [thread overview]
Message-ID: <4D59CDCA.6080102@gmail.com> (raw)
In-Reply-To: <15BCBB0C-5307-4AEC-8B48-7D8F4D16FB3B@gmail.com>
On 02/14/2011 03:42 PM, Peter LaDow wrote:
> Pseudo-code. I can post the full code if it helps.
>
My first thought was whether the compiler optimizes away the for loop.
Either way you would be hammering on the clock_gettime in a narly way,
it might be better just to hand-code a register read, if this is just
some kind of benchmark.
It would be good to know the time source chipset and its resolution.
what is the distribution for t2 - t1 btw?
for starters ;)
On Feb 14, 2011, at 3:35 PM, Sven-Thorsten Dietrich
<thebigcorporation@gmail.com> wrote:
>> On Mon, 2011-02-14 at 15:08 -0800, Peter LaDow wrote:
>>> Note sure how that is possible. This is related to my earlier posting
>>> about timing jitter. Our code is basically this:
>>>
>> Where is the semicolon ending the for loop?
>>
>>
>>> while(1)
>>> {
>>> t1 = clock_gettime()
>>> for(i=0; i< 10000; i++)
>>> t2 = clock_gettime()
>>>
>>> diff = t2 - 1
>>> }
>>>
>>> This task is pending on nothing. Unless clock_gettime() causes some
>>> sort of priority inversion, I don't see the problem. We see
>>> significant jitter on the for-loop when there are a significant number
>>> of other kernel timers. Now, as we understand it, the hrtimers run in
>>> the softirq. But if the softirq is priority 50, and this for-loop is
>>> priority 99, it shouldn't be affected by the softirq thread.
>>>
>>> Pete
>>>
>>> On Mon, Feb 14, 2011 at 3:04 PM, Sven-Thorsten Dietrich
>>> <thebigcorporation@gmail.com> wrote:
>>>> On Mon, 2011-02-14 at 14:31 -0800, Peter LaDow wrote:
>>>>> How is the scheduling of the hrtimers softirq thread handled?
>>>>>
>>>>> When querying the RT priority of the hrtimer softirq, I get a priority
>>>>> of 50. But when running a priority 99 thread, we still seem to be
>>>>> getting interrupted. Shouldn't the hrtimer softirq be put off until
>>>>> the CPU is idle or a lower priority task is running?
>>>> Does your prio 99 thread perhaps encounter a prio inversion dependency
>>>> on one of the softriq threads?
>>>>
>>>>> Thanks,
>>>>> Pete
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>
next prev parent reply other threads:[~2011-02-15 0:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-14 22:31 Interrupt Bottom Half Scheduling Peter LaDow
2011-02-14 23:04 ` Sven-Thorsten Dietrich
2011-02-14 23:08 ` Peter LaDow
2011-02-14 23:35 ` Sven-Thorsten Dietrich
2011-02-14 23:42 ` Peter LaDow
2011-02-15 0:50 ` Sven-Thorsten Dietrich [this message]
2011-02-14 23:30 ` Frank Rowand
2011-02-15 1:10 ` Peter LaDow
2011-02-15 1:58 ` Frank Rowand
2011-02-15 2:16 ` Frank Rowand
2011-02-15 16:42 ` Peter LaDow
2011-02-15 18:38 ` Frank Rowand
2011-02-15 18:40 ` Frank Rowand
2011-02-15 19:12 ` Peter LaDow
2011-02-15 19:35 ` Frank Rowand
2011-02-16 20:18 ` Peter LaDow
2011-02-15 8:40 ` Armin Steinhoff
2011-02-15 8:23 ` Uwe Kleine-König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D59CDCA.6080102@gmail.com \
--to=thebigcorporation@gmail.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=petela@gocougs.wsu.edu \
--cc=pladow@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).