mcm@peach.ucsb.edu (Marcelo C. Mourier) (05/30/90)
When clock_handler() finds out that an alarm has set off it issues an interrupt(CLOCK) to wake up the clock task. The clock task calls do_clocktick() to do the processing, which consists in scanning the entire proc table looking for a non-null p_alarm entry that is less than or equal to realtime. For speed's sake, wouldn't it be better if the alarms were kept in a linked list? This could be easily done by adding a new entry, p_nextalarm, to the proc structure that would keep the link between the proc table entries of the processes/tasks with pending alarms. In this way, finding the process/task to be awekened would require constant time, instead of O(n). Marcelo - mcm@cs.ucsb.edu
evans@ditsyda.oz (Bruce.Evans) (05/31/90)
In article <5544@hub.ucsb.edu> mcm@peach.ucsb.edu (Marcelo C. Mourier) writes: > For speed's sake, wouldn't it be better if the alarms were kept in a >linked list? This could be easily done by adding a new entry, p_nextalarm, to >the proc structure that would keep the link between the proc table entries of >the processes/tasks with pending alarms. In this way, finding the process/task >to be awekened would require constant time, instead of O(n). Sure it would be faster. It is not clear how much it would help. The clock task appears to be taking .0015% of the CPU on my system (386, no cron). A delta list would be faster still, and truly O(1). -- Bruce Evans evans@ditsyda.syd.dit.csiro.au