yeah, thanks for the reminder, this is on my todo list. As i suspect you
noticed it too, much of the task_struct size increase is not fundamental
and not related to 64-bit math at all - it's simply debug and
instrumentation overhead.
Look at the following table (i386, nodebug):
size
----
pre-CFS 1328
CFS 1472
CFS+patch 1376
the very small patch below gets rid of 96 bytes. And that's only the
beginning.
Ingo
-------------------------------------------------->
---
include/linux/sched.h | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
Index: linux/include/linux/sched.h
===================================================================
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -905,23 +905,28 @@ struct sched_entity {
struct rb_node run_node;
unsigned int on_rq;
+ u64 exec_start;
+ u64 sum_exec_runtime;
u64 wait_start_fair;
+ u64 sleep_start_fair;
+
+#ifdef CONFIG_SCHEDSTATS
u64 wait_start;
- u64 exec_start;
+ u64 wait_max;
+ s64 sum_wait_runtime;
+
u64 sleep_start;
- u64 sleep_start_fair;
- u64 block_start;
u64 sleep_max;
+ s64 sum_sleep_runtime;
+
+ u64 block_start;
u64 block_max;
u64 exec_max;
- u64 wait_max;
- u64 last_ran;
- u64 sum_exec_runtime;
- s64 sum_wait_runtime;
- s64 sum_sleep_runtime;
unsigned long wait_runtime_overruns;
unsigned long wait_runtime_underruns;
+#endif
+
#ifdef CONFIG_FAIR_GROUP_SCHED
struct sched_entity *parent;
/* rq on which this entity is (to be) queued: */
-
