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.
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.
also re overhead. the cost of servicing 10 times as many interrupts as
necessary for system function must cost a fair chunk.
-
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/