Mark Salisbury wrote:
>
> > 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.
>
> actually, I think a head and tail pointer would be sufficient for most
> cases. (most new timers are either going to be a new head of list or a new
> tail, i.e. long duration timeouts that will never be serviced or short
> duration timers that are going to go off "real soon now (tm)") the oddball
> cases would be mostly coming from user-space, i.e. nanosleep which a longerr
> list insertion disapears in the block/wakeup/context switch overhead
>
> > >
> > > 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.
> > 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?
>
> time accounting can be limited to the quantum expiration and voluntary
> yields in the tickless/useless case.
>
> > 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.
>
> I agree that some combinations don't make much sense _TO_ME_ but that
> doesn't mean they don't meet sombody's needs.
>
> in my case (embedded, medium hard real time, massively parallel
> multicomputer) the only choices that makes sense to my customers is
> tickless/useless in deployment and tickless/useful in
> development/profiling/optimization.
I suspect you might go for ticked if its overhead was less. The thing
that makes me think the overhead is high for tick less is the accounting
and time slice stuff. This has to be handled each system call and each
schedule call. These happen WAY more often than ticks... Contrary
wise, I would go for tick less if its overhead is the same or less under
a reasonable load. Of course, we would also want to check overload
sensitivity.
>
> in other cases ticked/useless makes sense (dumb old slow chips)
>
> I have no idea who would want ticked/useful or hybrid. i suggested hybrid
> as an alternative in case linus might be reluctant to gutting and replacing
> the sysclock.
>
> >
> > 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.
>
> no. you would re-use the timer with a new expiration time and a re-insert.
The issue is not the timer structure itself, but the insert and removal
time AND the time accounting that would have to go on around it. The
timer would need to be computed and started each time on the way out of
schedule and stopped and the residue saved on schedule entry. One might
want to roll this into the accounting time stuff...
>
> also re overhead. the cost of servicing 10 times as many interrupts as
> necessary for system function must cost a fair chunk.
>
On a half way loaded system? Do you think it is that high? I sort of
think that, once the system is loaded, there would be a useful timer
tick most of the time. Might be useful to do some measurements of this.
George
-
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:15 EST