On Wed, 2005-07-27 at 23:32 +0200, Esben Nielsen wrote:
>
> This is rate monotonic scheduling
> (http://en.wikipedia.org/wiki/Rate-monotonic_scheduling).
Bingo! you win the cigar!
> ((Notice: The article gets it wrong on the priority inheritance/ceiling
> stuff...))
It's too early in the mornin
On Thu, 2005-07-28 at 09:22 +0200, Ingo Molnar wrote:
> nitpicking: i guess the answer also depends on what the precise
> requirement is. If the requirement is 'run for 4 seconds every 10
> seconds, uninterrupted, else the power plant melts down', i'd sure not
> make the washing machine process
On Wed, 27 Jul 2005, K.R. Foley wrote:
> Esben Nielsen wrote:
> [...]
>
> All of the RT priorities that we have are not absolutely necessary. As I
> think Steven pointed out in another email, it is nice though to be able
> to priortize tasks using large jumps in priorities and then being able
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > a fair number of apps assume that there's _at least_ 100 levels of
> > priorities. The moment you have a custom kernel that offers more than
> > 100 priorities, there will be apps that assume that there are more than
> > 100 priority levels, and
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> A colleague of mine, well actually the VP of my company of the time,
> Doug Locke, gave me a perfect example. If you have a program that
> runs a nuclear power plant that needs to wake up and run 4 seconds
> every 10 seconds, and on that same comp
Steven Rostedt wrote:
OK, still looks like the generic ffb can be changed. Unless I'm missing
something, this shows that I probably should be sending in a patch now
to replace the find_first_bit. Ingo's sched_find_first_bit is still the
winner, but that is customed to the scheduler, until we n
On Wed, 2005-07-27 at 23:32 -0400, Steven Rostedt wrote:
> New benchmarks with my own formula.
>
Take two: I ran this on my laptop (IBM ThinkPad G41 with an 3.3GHz
Pentium 4 HT processor, yeah yeah, no battery life :-). But this has an
older compiler.
$ gcc -v
Reading specs from /usr/lib/gcc-li
New benchmarks with my own formula.
I added my own find_first_bit algorithm, that still doesn't quite beat
Ingo's sched_find_first_bit, but it does a number on the generic
find_first_bit. I guess the compiler has finally beat what we do in
asm. Here's my generic algorithm.
static inline int my_
On Wed, 2005-07-27 at 21:25 -0400, Steven Rostedt wrote:
> On Wed, 2005-07-27 at 18:00 -0700, Daniel Walker wrote:
> > Don't you break sched_find_first_bit() , seems it's dependent on a
> > 140-bit bitmap .
>
> Oops! I forgot about that. With my custom kernels I had to change this
> to use the ge
On Wed, Jul 27, 2005 at 04:17:54PM +0200, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > The following patch makes the MAX_RT_PRIO and MAX_USER_RT_PRIO
> > configurable from the make *config. This is more of a proposal since
> > I'm not really sure where in Kconfig th
On Wed, 2005-07-27 at 18:00 -0700, Daniel Walker wrote:
> Don't you break sched_find_first_bit() , seems it's dependent on a
> 140-bit bitmap .
Oops! I forgot about that. With my custom kernels I had to change this
to use the generic find_first_bit routine. It's been a while since I
made these ch
On Wed, 2005-07-27 at 21:20 -0400, Lee Revell wrote:
> On Wed, 2005-07-27 at 18:00 -0700, Daniel Walker wrote:
> > Don't you break sched_find_first_bit() , seems it's dependent on a
> > 140-bit bitmap .
>
> And doesn't POSIX specify 100 RT priority levels?
My customers don't care about POSIX :-)
On Wed, 2005-07-27 at 18:00 -0700, Daniel Walker wrote:
> Don't you break sched_find_first_bit() , seems it's dependent on a
> 140-bit bitmap .
And doesn't POSIX specify 100 RT priority levels?
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
Don't you break sched_find_first_bit() , seems it's dependent on a
140-bit bitmap .
Daniel
On Wed, 2005-07-27 at 10:13 -0400, Steven Rostedt wrote:
> The following patch makes the MAX_RT_PRIO and MAX_USER_RT_PRIO
> configurable from the make *config. This is more of a proposal since
> I'm not
On Wed, 27 Jul 2005, Steven Rostedt wrote:
> On Wed, 2005-07-27 at 19:01 +0200, Esben Nielsen wrote:
> >
> > What for? Why can't you use FIFO at the same priorities for some of your
> > tasks? I pretty much quess you have a very few tasks which have some high
> > requirements. The rest of you "RT
Esben Nielsen wrote:
On Wed, 27 Jul 2005, K.R. Foley wrote:
Esben Nielsen wrote:
On Wed, 27 Jul 2005, Ingo Molnar wrote:
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
Perfectly understood. I've had two customers ask me to increase the
priorities for them, but those where custom kernel
On Wed, 2005-07-27 at 19:01 +0200, Esben Nielsen wrote:
>
> What for? Why can't you use FIFO at the same priorities for some of your
> tasks? I pretty much quess you have a very few tasks which have some high
> requirements. The rest of you "RT" task could easily share the lowest RT
> priority. FI
On Wed, 27 Jul 2005, K.R. Foley wrote:
> Esben Nielsen wrote:
> > On Wed, 27 Jul 2005, Ingo Molnar wrote:
> >
> >
> >>* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>Perfectly understood. I've had two customers ask me to increase the
> >>>priorities for them, but those where custom
Esben Nielsen wrote:
On Wed, 27 Jul 2005, Ingo Molnar wrote:
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
Perfectly understood. I've had two customers ask me to increase the
priorities for them, but those where custom kernels, and a config
option wasn't necessary. But since I've had custom
On Wed, 2005-07-27 at 16:53 +0200, Esben Nielsen wrote:
> Isn't there a way to mark it "warning! warning! dangerous!" ?
Sure,
config MAX_RT_PRIO
int "Maximum RT priority (DANGEROUS!)"
>
> Anyway: I think 100 RT priorities is way overkill - and slowing things
> down by making the schedul
On Wed, 27 Jul 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Perfectly understood. I've had two customers ask me to increase the
> > priorities for them, but those where custom kernels, and a config
> > option wasn't necessary. But since I've had customers ask
On Wed, 2005-07-27 at 16:38 +0200, Ingo Molnar wrote:
> a fair number of apps assume that there's _at least_ 100 levels of
> priorities. The moment you have a custom kernel that offers more than
> 100 priorities, there will be apps that assume that there are more than
> 100 priority levels, and
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-07-27 at 16:17 +0200, Ingo Molnar wrote:
> > i'd not do this patch, mainly because the '100 priority levels' thing is
> > pretty much an assumption in lots of userspace code.
>
> I must argue though, any user app that assumes 100 is th
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Perfectly understood. I've had two customers ask me to increase the
> priorities for them, but those where custom kernels, and a config
> option wasn't necessary. But since I've had customers asking, I
> thought that this might be something that o
On Wed, 2005-07-27 at 16:17 +0200, Ingo Molnar wrote:
> i'd not do this patch, mainly because the '100 priority levels' thing is
> pretty much an assumption in lots of userspace code.
I must argue though, any user app that assumes 100 is the max prio is
already broken. That's why there are syst
On Wed, 2005-07-27 at 16:17 +0200, Ingo Molnar wrote:
> i'd not do this patch, mainly because the '100 priority levels' thing is
> pretty much an assumption in lots of userspace code. The patch to make
> it easier to redefine it is of course fine and was accepted, but i dont
> think we want to m
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> The following patch makes the MAX_RT_PRIO and MAX_USER_RT_PRIO
> configurable from the make *config. This is more of a proposal since
> I'm not really sure where in Kconfig this would best fit. I don't see
> why these options shouldn't be user con
27 matches
Mail list logo
