public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: William Cohen <wcohen@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Size of 2.6.20 task_struct on x86_64 machines
Date: Sat, 10 Feb 2007 19:20:20 -0500	[thread overview]
Message-ID: <20070211002020.GA6849@redhat.com> (raw)
In-Reply-To: <45CB4C55.4070902@redhat.com>

On Thu, Feb 08, 2007 at 11:14:13AM -0500, William Cohen wrote:
 > 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

I sent this .. http://lkml.org/lkml/2007/1/2/299
last month which shrinks task struct by 480 bytes when lockdep
is enabled. Ingo acked it, but then it fell on the floor.

Here it is again..

		Dave

Shrink the held_lock struct by using bitfields.
This shrinks task_struct on lockdep enabled kernels by 480 bytes.

Signed-off-by: Dave Jones <davej@redhat.com>

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index ea097dd..ba81cce 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -175,11 +175,11 @@ struct held_lock {
 	 * The following field is used to detect when we cross into an
 	 * interrupt context:
 	 */
-	int				irq_context;
-	int				trylock;
-	int				read;
-	int				check;
-	int				hardirqs_off;
+	unsigned char irq_context:1;
+	unsigned char trylock:1;
+	unsigned char read:2;
+	unsigned char check:1;
+	unsigned char hardirqs_off:1;
 };
 
 /*

-- 
http://www.codemonkey.org.uk

  parent reply	other threads:[~2007-02-11  0:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-08 16:14 Size of 2.6.20 task_struct on x86_64 machines William Cohen
2007-02-08 20:19 ` David Miller
2007-02-08 21:03   ` Andrew Morton
2007-02-11  0:20 ` Dave Jones [this message]
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=20070211002020.GA6849@redhat.com \
    --to=davej@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=wcohen@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox