From: George Anzinger <george@mvista.com>
To: dwalker@mvista.com
Cc: tglx@linutronix.de, john stultz <johnstul@us.ibm.com>,
Nish Aravamudan <nish.aravamudan@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
"'high-res-timers-discourse@lists.sourceforge.net'"
<high-res-timers-discourse@lists.sourceforge.net>
Subject: Re: 2.6.13-rt6, ktimer subsystem
Date: Thu, 15 Sep 2005 17:08:33 -0700 [thread overview]
Message-ID: <432A0D01.7010303@mvista.com> (raw)
In-Reply-To: <1126825796.4576.31.camel@dhcp153.mvista.com>
Daniel Walker wrote:
> On Thu, 2005-09-15 at 15:35 -0700, George Anzinger wrote:
>
>>In the early HRT patches the whole timer list was replaced with a hashed
>>list. It was O(N/M) on insertion where we could easily choose M (for a
>>while it was even a config option). Removal was just an unlink, same as
>>the cascade list.
>>
>>To be clear on my take on this, as I understand it the rblist is
>>something like O(N*somelog 2). What is left out here is the fixed
>>overhead of F which is there even if N = 1. So we have something like
>>(F+O(f(N)) for a list. For the most part we don't look at F, but as
>>list complexity grows, it gets larger thus pushing out the cross over
>>point to a higher "N" when comparing two lists. I considered the rbtree
>>when doing the secondary list for HRT and concluded that "N" was small
>>enough that a simple O(N/2) list would do just fine as it would only
>>contain timers set to expire in the next jiffie.
>
>
> The fact that we know in advance that a system is only going to a very
> small number of these timers should be noted. You could just use a
> regular list , and limit the total number of timers . I would hesitate
> to stick a big data structure in when your only dealing with one or two
> timers on average..
>
> George, what's largest number of highres timers that someone might
> need/want?
>
Well, the interesting thing is that, unless you change something, the
system has a current limit of 1000 posix timers. This can be changed,
but, I suspect it is not changed very often. And this handles all posix
timers, low and high res. Sleep is another thing, with a max of one
sleep timer per task. The ktimer list is also doing itimers, which are
also limited to the number of tasks.
As for data structures, a hashed list requires a "list head" for each
bucket while, I think the rblist only has one list head, but requires an
additional list head (or is it two) in the entry data structure so this
is a pay as you go list.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
next prev parent reply other threads:[~2005-09-16 0:09 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-13 10:00 2.6.13-rt6, ktimer subsystem Ingo Molnar
2005-09-13 19:59 ` Lee Revell
2005-09-13 20:06 ` Lee Revell
2005-09-13 20:10 ` Ingo Molnar
2005-09-13 20:36 ` Lee Revell
2005-09-15 7:55 ` Ingo Molnar
2005-09-15 11:37 ` Ingo Molnar
2005-09-14 15:56 ` Darren Hart
2005-09-14 22:09 ` Darren Hart
2005-09-14 19:38 ` George Anzinger
2005-09-15 2:25 ` Thomas Gleixner
2005-09-15 22:35 ` George Anzinger
2005-09-15 22:53 ` Thomas Gleixner
2005-09-15 23:10 ` George Anzinger
2005-09-15 23:09 ` Daniel Walker
2005-09-16 0:08 ` George Anzinger [this message]
2005-09-15 9:20 ` Ingo Molnar
2005-09-15 23:04 ` George Anzinger
2005-09-15 23:20 ` Thomas Gleixner
2005-09-15 9:43 ` Roman Zippel
2005-09-26 7:02 ` 2.6.14-rc2-rt2 Ingo Molnar
2005-09-27 6:13 ` 2.6.14-rc2-rt2 Eran Mann
2005-09-27 10:33 ` 2.6.14-rc2-rt2 Ingo Molnar
2005-09-27 16:59 ` 2.6.14-rc2-rt2 Fernando Lopez-Lezcano
2005-09-27 22:15 ` 2.6.14-rc2-rt2 Thomas Gleixner
2005-09-27 23:11 ` 2.6.14-rc2-rt2 Fernando Lopez-Lezcano
2005-09-27 23:10 ` 2.6.14-rc2-rt2 Daniel Walker
2005-09-28 3:04 ` 2.6.14-rc2-rt2 Fernando Lopez-Lezcano
2005-09-28 9:48 ` 2.6.14-rc2-rt2 Ingo Molnar
2005-09-28 16:34 ` 2.6.14-rc2-rt2 Fernando Lopez-Lezcano
2005-09-29 9:07 ` 2.6.14-rc2-rt2 Eran Mann
2005-09-28 9:10 ` 2.6.14-rc2-rt2 Peter Zijlstra
2005-09-29 16:45 ` 2.6.14-rc2-rt2 Badari Pulavarty
2005-09-30 10:58 ` 2.6.14-rc2-rt2 Ingo Molnar
2005-10-02 15:18 ` 2.6.14-rc3-rt1 Ingo Molnar
2005-10-02 15:42 ` 2.6.14-rc3-rt1 Mark Knecht
2005-10-02 19:25 ` 2.6.14-rc3-rt1 Mark Knecht
2005-10-06 17:13 ` 2.6.14-rc3-rt1 Steven Rostedt
2005-10-07 11:09 ` [patch] pcmcia-shutdown-fix.patch Ingo Molnar
2005-10-07 19:17 ` Russell King
2005-10-07 19:46 ` Steven Rostedt
2005-10-10 15:13 ` Steven Rostedt
2005-10-10 15:37 ` Steven Rostedt
2005-10-02 20:51 ` 2.6.14-rc3-rt1 Felix Oxley
2005-10-02 21:55 ` 2.6.14-rc3-rt1 Felix Oxley
2005-10-03 6:33 ` 2.6.14-rc3-rt1 Ingo Molnar
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=432A0D01.7010303@mvista.com \
--to=george@mvista.com \
--cc=dwalker@mvista.com \
--cc=high-res-timers-discourse@lists.sourceforge.net \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nish.aravamudan@gmail.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.