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.
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.
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.
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.
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.
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