[lkml]   [2001]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: No 100 HZ timer !
    Jamie Locker wrote:
    > Mark Salisbury wrote:
    > > > 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
    > A pointer-based priority queue is really not a very complex thing, and
    > there are ways to optimise them for typical cases like the above.
    Please do enlighten me. The big problem in my mind is that the
    pointers, pointing at points in time, are perishable.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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