mark salisbury wrote:
>
> george anzinger wrote:
>
> > f) As noted, the account timers (task user/system times) would be much
> > more accurate with the tick less approach. The cost is added code in
> > both the system call and the schedule path.
> >
> > Tentative conclusions:
> >
> > Currently we feel that the tick less approach is not acceptable due to
> > (f). We felt that this added code would NOT be welcome AND would, in a
> > reasonably active system, have much higher overhead than any savings in
> > not having a tick. Also (d) implies a list organization that will, at
> > the very least, be harder to understand. (We have some thoughts here,
> > but abandoned the effort because of (f).) We are, of course, open to
> > discussion on this issue and all others related to the project
> > objectives.
>
> f does not imply tick-less is not acceptable, it implies that better process time
> accounting is not acceptable.
My thinking is that a timer implementation that forced (f) would have
problems gaining acceptance (even with me :). I think a tick less
system does force this and this is why we have, at least for the moment,
abandoned it. In no way does this preclude (f) as it is compatible with
either ticks or tick less time keeping. On the other hand, the stated
project objectives do not include (f) unless, of course we do a tick
less time system.
>
> list organization is not complex, it is a sorted absolute time list. I would
> argue that this is a hell of a lot easier to understand that ticks + offsets.
The complexity comes in when you want to maintain indexes into the list
for quick insertion of new timers. To get the current insert
performance, for example, you would need pointers to (at least) each of
the next 256 centasecond boundaries in the list. But the list ages, so
these pointers need to be continually updated. The thought I had was to
update needed pointers (and only those needed) each time an insert was
done and a needed pointer was found to be missing or stale. Still it
adds complexity that the static structure used now doesn't have.
>
> still, better process time accounting should be a compile CONFIG option, not
> ignored and ruled out because some one thinks that is is to expensive in the
> general case.
As I said above, we are not ruling it out, but rather, we are not
requiring it by going tick less.
>
> the whole point of linux and CONFIG options is to get you the kernel with the
> features you want, not what someone else wants.
>
> there should be a whole range of config options associated with this issue:
>
> CONFIG_JIFFIES == old jiffies implementation
> CONFIG_TICKLESS == tickless
> CONFIG_HYBRID == old jiffies plus a tickless high-res timer system on
> the side but not assoc w/ process and global
> timekeeping
>
> CONFIG_USELESS_PROCESS_TIME_ACCOUNTING = old style, cheap time acctg
> CONFIG_USEFUL_BUT_COSTS_TIME_ACCOUNTING = accurate but expensive time accounting
>
> this way, users who want tickless and lousy time acctg can have it AND people who
> want jiffies and good time acctg could have it.
As I said, it is not clear how you could get
CONFIG_USELESS_PROCESS_TIME_ACCOUNTING unless you did a tick every
jiffie. What did you have in mind?
>
> these features are largely disjoint and easily seperable. it is also relatively
> trivial to do this in such a way that drivers depending on the jiffie abstraction
> can be supported without modification no matter what the configuration.
>
For the most part, I agree. I am not sure that it makes a lot of sense
to mix some of these options, however. I think it comes down to the
question of benefit vs cost. If keeping an old version around that is
not any faster or more efficient in any way would seem too costly to
me. We would like to provide a system that is better in every way and
thus eliminate the need to keep the old one around. We could leave it
in as a compile option so folks would have a fall back, I suppose.
An Issue no one has raised is that the tick less system would need to
start a timer each time it scheduled a task. This would lead to either
slow but very precise time slicing or about what we have today with more
schedule overhead.
George
> Mark Salisbury
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 15 2001 - 21:00:14 EST