lkml.org 
[lkml]   [2004]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: gradual timeofday overhaul
Date
From
> From: George Anzinger [mailto:george@mvista.com]
>
> Perez-Gonzalez, Inaky wrote:
>
> > But you can also schedule, before switching to the new task,
> > a local interrupt on the running processor to mark the end
> > of the timeslice. When you enter the scheduler, you just need
> > to remove that; devil is in the details, but it should be possible
> > to do in a way that doesn't take too much overhead.
>
> Well, that is part of the accounting overhead the increases with context switch
> rate. You also need to include the time it takes to figure out which of the
> time limits is closes (run time limit, profile time, slice time, etc). Then,

I know these are specific examples, but:

- profile time is a periodic thingie, so if you have it, forget about
having a tickless system. Periodic interrupt for this guy, get it
out of the equation.

- slice time vs runtime limit. I don't remember what is the granularity of
the runtime limit, but it could be expressed in slice terms. If not,
we are talking (along with any other times) of min() operations, which
are just a few cycles each [granted, they add up].

> you also need to remove the timer when switching away. No, it is not a lot, but
> it is way more than the nothing we do when we can turn it all over to the
> periodic tick. The choice is load sensitive overhead vs flat overhead.

This is just talking out of my ass, but I guess that for each invocation
they will have more or less the same overhead in execution time, let's
say T. For the periodic tick, the total overhead (in a second) is T*HZ;
with tickless, it'd be T*number_of_context_switches_per_second, right?

Now, the ugly case would be if number_of_context_swiches_per_second > HZ.
In HZ = 100, this could be happening, but in HZ=1000, in a single CPU
...well, that would be TOO weird [of course, a real-time app with a
1ms period would do that, but it'd require at least an HZ of 10000 to
work more or less ok and we'd be below the watermark].

So in most cases, and given the assumptions, we'd end up winning,
beause number_of_context..., even if variable, is going to be bound
on the upper side by HZ.

Well, you know way more than I do about this, so here is the question:
what is the error in that line of reasoning?

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.039 / U:0.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site