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]
