summaryrefslogtreecommitdiffstats
path: root/fs/gfs2/glock.h
diff options
context:
space:
mode:
authorWilliam Cohen <wcohen@redhat.com>2007-05-08 09:23:41 +0200
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-05-08 20:14:58 +0200
commit97dc32cdb1b53832801159d5f634b41aad9d0a23 (patch)
tree438f59c84d3528de5f68583d312beceb1aa32659 /fs/gfs2/glock.h
parentext2/3/4: fix file date underflow on ext2 3 filesystems on 64 bit systems (diff)
downloadlinux-97dc32cdb1b53832801159d5f634b41aad9d0a23.tar.xz
linux-97dc32cdb1b53832801159d5f634b41aad9d0a23.zip
reduce size of task_struct on 64-bit machines
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 [akpm@linux-foundation.org: fix printk warnings] Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/gfs2/glock.h')
0 files changed, 0 insertions, 0 deletions