Jason Thorpe wrote:

> On Oct 23, 2007, at 5:10 AM, Joerg Sonnenberger wrote:
> 
> > For callout_stop, I would expect it to be a relative rare operation,  
> > so
> > optimising that doesn't matter. callout_reset/callout_schedule  
> > happens a
> > lot more often, but I don't think it is performance critical either.  
> > It
> > happens a lot to extend the trigger period and it should be analyzed  
> > if
> > a lazy update of the tree is more efficient. I doubt it though.
> 
> 
> callout_stop() is actually a fairly frequent operation.  It's used to  
> detect timeouts on I/O operations for e.g. SCSI and ATA commands.

Just for kicks, here some event counters on a Core Duo laptop.  This is
after a kernel had finished building after a reboot.  The system had
been up for about 8 minutes at this stage.

event                                         total     rate type
callout late                                      9        0 misc
callout ack                                      10        0 misc
callout active                                13865       33 misc
callout destroy                               11366       27 misc
callout init                                  11660       27 misc
callout invoking                                 47        0 misc
callout pending                                 113        0 misc
callout reset                                 83970      201 misc
callout schedule                              46165      110 misc
callout setfunc                               11467       27 misc
callout stop                                 101361      243 misc

Cheers,
Simon.