All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Cohen <wcohen@redhat.com>
To: linux-kernel@vger.kernel.org
Subject: Size of 2.6.20 task_struct on x86_64 machines
Date: Thu, 08 Feb 2007 11:14:13 -0500	[thread overview]
Message-ID: <45CB4C55.4070902@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

This past week I was playing around with that pahole tool
(http://oops.ghostprotocols.net:81/acme/dwarves/) and looking at the
size of various struct in the kernel. I was surprised by the size of
the task_struct on x86_64, approaching 4K.  I looked through the
fields in task_struct and found that a number of them were declared as
"unsigned long" rather than "unsigned int" despite them appearing okay
as 32-bit sized fields. On x86_64 "unsigned long" ends up being 8
bytes in size and forces 8 byte alignment. Is there a reason there
a reason they are "unsigned long"?

The patch below drops the size of the struct from 3808 bytes (60
64-byte cachelines) to 3760 bytes (59 64-byte cachelines). A couple
other fields in the task struct take a signficant amount of space:

struct thread_struct       thread;               688
struct held_lock           held_locks[30];       1680

CONFIG_LOCKDEP is turned on in the .config

-Will

[-- Attachment #2: task_struct_compress.diff --]
[-- Type: text/x-patch, Size: 1363 bytes --]

--- include/linux/sched.h.compress	2007-02-06 16:16:14.000000000 -0500
+++ include/linux/sched.h	2007-02-07 18:09:34.000000000 -0500
@@ -802,8 +802,8 @@
 	volatile long state;	/* -1 unrunnable, 0 runnable, >0 stopped */
 	struct thread_info *thread_info;
 	atomic_t usage;
-	unsigned long flags;	/* per process flags, defined below */
-	unsigned long ptrace;
+	unsigned int flags;	/* per process flags, defined below */
+	unsigned int ptrace;
 
 	int lock_depth;		/* BKL lock depth */
 
@@ -826,7 +826,7 @@
 	unsigned long long sched_time; /* sched_clock time spent running */
 	enum sleep_type sleep_type;
 
-	unsigned long policy;
+	unsigned int policy;
 	cpumask_t cpus_allowed;
 	unsigned int time_slice, first_time_slice;
 
@@ -846,11 +846,11 @@
 
 /* task state */
 	struct linux_binfmt *binfmt;
-	long exit_state;
+	int exit_state;
 	int exit_code, exit_signal;
 	int pdeath_signal;  /*  The signal sent when the parent dies  */
 	/* ??? */
-	unsigned long personality;
+	unsigned int personality;
 	unsigned did_exec:1;
 	pid_t pid;
 	pid_t tgid;
@@ -882,7 +882,7 @@
 	int __user *set_child_tid;		/* CLONE_CHILD_SETTID */
 	int __user *clear_child_tid;		/* CLONE_CHILD_CLEARTID */
 
-	unsigned long rt_priority;
+	unsigned int rt_priority;
 	cputime_t utime, stime;
 	unsigned long nvcsw, nivcsw; /* context switch counts */
 	struct timespec start_time;

             reply	other threads:[~2007-02-08 16:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08 16:14 William Cohen [this message]
2007-02-08 20:19 ` Size of 2.6.20 task_struct on x86_64 machines David Miller
2007-02-08 21:03   ` Andrew Morton
2007-02-11  0:20 ` Dave Jones
2007-02-11  2:55   ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45CB4C55.4070902@redhat.com \
    --to=wcohen@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.