Re: [Patch 1/4] Delay accounting: Initialization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Nov 14, 2005, at 11:35 PM, Shailabh Nagar wrote:

+/* because of hardware timer drifts in SMPs and task continue on different cpu
+ * then where the start_ts was taken there is a possibility that
+ * end_ts < start_ts by some usecs. In this case we ignore the diff
+ * and add nothing to the total.

Curious as to when would this occur. Probably for tasks running on a SMP machine for a very short period of time (timer drift should not be hopefully that high) and switching CPUs in that short period of time?

+config STATS_CONNECTOR
+config DELAY_ACCT

Probably TASK_DELAY_STATS_CONNECTOR and TASK_DELAY_ACCOUNTING are better names?

@@ -813,6 +821,9 @@ struct task_struct {
 	int cpuset_mems_generation;
 #endif
 	atomic_t fs_excl;	/* holding fs exclusive resources */
+#ifdef	CONFIG_DELAY_ACCT
+	struct task_delay_info delays;
+#endif
 };

Does this mean, whether or not the per task delay accounting is used, we have a constant overhead of sizeof(spinlock_t) + 2*sizeof (uint32_t) + 2* sizeof(uint64_t) bytes going into the struct task_struct?. Is it possible/beneficial to use struct task_delay_info *delays instead and allocate it if task wants to use the information?

Parag
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux