All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <iod00d@hp.com>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: 'Grant Grundler' <iod00d@hp.com>,
	'Christoph Hellwig' <hch@infradead.org>,
	'Akinobu Mita' <mita@miraclelinux.com>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>,
	linux-ia64@vger.kernel.org
Subject: Re: [PATCH 1/12] generic *_bit()
Date: Wed, 01 Feb 2006 22:09:03 +0000	[thread overview]
Message-ID: <20060201220903.GE16471@esmail.cup.hp.com> (raw)
In-Reply-To: <200602012141.k11LfCg32497@unix-os.sc.intel.com>

On Wed, Feb 01, 2006 at 01:41:03PM -0800, Chen, Kenneth W wrote:
> > Well, if it doesn't matter, why is unsigned int better?
> 
> I was coming from the angle of having bitop operate on unsigned
> int *, so people don't have to type cast or change bit flag variable
> to unsigned long for various structures.  With unsigned int type for
> bit flag, some of them are not even close to fully utilized. for example:
> 
> thread_info->flags uses 18 bits
> thread_struct->flags uses 7 bits
> 
> It's a waste of memory to define a variable that kernel will *never*
> touch the 4 MSB in that field.

Agreed. Good point. But this can be mitigated if the code using "unsigned int"
(or unsigned byte) first loads the value into a local unsigned long variable.
That typically translates into a tmp register anyway. Compiler will help
you find places where that needs to happen.

Counter point is bit arrays (e.g. bit maps) like cpumask_t are
typically much larger than 32-bits (typically distro's ship with
NR_CPUS set to 256 or so).  File system code also likes bit arrays
for block allocation tables. Searching a bit array using unsigned
long is 2x faster on 64-bit architectures. I don't want to give
that up and I'm pretty sure Tony Luck, Paul Mckerras and a few
others would object unless you can give a better reason.

Obviously neither memory footprint nor speed of walking memory is an
the issue for 32-bit arches (where unsigned long = unsigned int).


> > unsigned long is typically the native register size, right?
> > I'd expect that to be more efficient on most arches.
> 
> The only difference that I can think of on Itanium processor is the
> memory operation, you either load/store 4 or 8 bytes. Once the data
> is in the CPU register, it doesn't make any difference whether it is
> operating on 32bit or entire 64 bit. I don't know about others RISC
> arch though whether it is more efficient with native register size.

agreed. I was thinking mostly of the bit map search - not searching
within a single unsigned int.

grant

WARNING: multiple messages have this Message-ID (diff)
From: Grant Grundler <iod00d@hp.com>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: "'Grant Grundler'" <iod00d@hp.com>,
	"'Christoph Hellwig'" <hch@infradead.org>,
	"'Akinobu Mita'" <mita@miraclelinux.com>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>,
	linux-ia64@vger.kernel.org
Subject: Re: [PATCH 1/12] generic *_bit()
Date: Wed, 1 Feb 2006 14:09:03 -0800	[thread overview]
Message-ID: <20060201220903.GE16471@esmail.cup.hp.com> (raw)
In-Reply-To: <200602012141.k11LfCg32497@unix-os.sc.intel.com>

On Wed, Feb 01, 2006 at 01:41:03PM -0800, Chen, Kenneth W wrote:
> > Well, if it doesn't matter, why is unsigned int better?
> 
> I was coming from the angle of having bitop operate on unsigned
> int *, so people don't have to type cast or change bit flag variable
> to unsigned long for various structures.  With unsigned int type for
> bit flag, some of them are not even close to fully utilized. for example:
> 
> thread_info->flags uses 18 bits
> thread_struct->flags uses 7 bits
> 
> It's a waste of memory to define a variable that kernel will *never*
> touch the 4 MSB in that field.

Agreed. Good point. But this can be mitigated if the code using "unsigned int"
(or unsigned byte) first loads the value into a local unsigned long variable.
That typically translates into a tmp register anyway. Compiler will help
you find places where that needs to happen.

Counter point is bit arrays (e.g. bit maps) like cpumask_t are
typically much larger than 32-bits (typically distro's ship with
NR_CPUS set to 256 or so).  File system code also likes bit arrays
for block allocation tables. Searching a bit array using unsigned
long is 2x faster on 64-bit architectures. I don't want to give
that up and I'm pretty sure Tony Luck, Paul Mckerras and a few
others would object unless you can give a better reason.

Obviously neither memory footprint nor speed of walking memory is an
the issue for 32-bit arches (where unsigned long == unsigned int).


> > unsigned long is typically the native register size, right?
> > I'd expect that to be more efficient on most arches.
> 
> The only difference that I can think of on Itanium processor is the
> memory operation, you either load/store 4 or 8 bytes. Once the data
> is in the CPU register, it doesn't make any difference whether it is
> operating on 32bit or entire 64 bit. I don't know about others RISC
> arch though whether it is more efficient with native register size.

agreed. I was thinking mostly of the bit map search - not searching
within a single unsigned int.

grant

  reply	other threads:[~2006-02-01 22:09 UTC|newest]

Thread overview: 265+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-25 11:26 [PATCH 0/6] RFC: use include/asm-generic/bitops.h Akinobu Mita
2006-01-25 11:26 ` Akinobu Mita
2006-01-25 11:26 ` Akinobu Mita
2006-01-25 11:26 ` Akinobu Mita
2006-01-25 11:26 ` Akinobu Mita
2006-01-25 11:28 ` [PATCH 1/6] {set,clear,test}_bit() related cleanup Akinobu Mita
2006-01-25 11:28   ` Akinobu Mita
2006-01-25 11:28   ` Akinobu Mita
2006-01-25 11:28   ` Akinobu Mita
2006-01-25 11:28   ` Akinobu Mita
2006-01-25 11:46   ` Andi Kleen
2006-01-25 11:46     ` Andi Kleen
2006-01-26 16:14   ` Pavel Machek
2006-01-26 16:14     ` Pavel Machek
2006-01-26 16:14     ` Pavel Machek
2006-01-26 16:14     ` Pavel Machek
2006-01-26 16:14     ` Pavel Machek
2006-01-26 16:47     ` Russell King
2006-01-26 16:47       ` Russell King
2006-01-26 16:47       ` Russell King
2006-01-26 16:47       ` Russell King
2006-01-26 16:47       ` Russell King
2006-01-26 19:14     ` Paul Jackson
2006-01-26 19:14       ` Paul Jackson
2006-01-26 19:14       ` Paul Jackson
2006-01-25 11:30 ` [PATCH 2/6] use non atomic operations for minix_*_bit() and ext2_*_bit() Akinobu Mita
2006-01-25 11:30   ` Akinobu Mita
2006-01-25 11:30   ` Akinobu Mita
2006-01-25 11:30   ` Akinobu Mita
2006-01-25 11:30   ` Akinobu Mita
2006-01-25 11:32 ` [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h Akinobu Mita
2006-01-25 11:32   ` Akinobu Mita
2006-01-25 11:32   ` Akinobu Mita
2006-01-25 11:32   ` Akinobu Mita
2006-01-25 11:32   ` Akinobu Mita
2006-01-25 11:54   ` Keith Owens
2006-01-25 11:54     ` Keith Owens
2006-01-25 11:54     ` Keith Owens
2006-01-25 11:54     ` Keith Owens
2006-01-25 11:54     ` Keith Owens
2006-01-25 11:54     ` Keith Owens
2006-01-26  2:13     ` Akinobu Mita
2006-01-26  2:13       ` Akinobu Mita
2006-01-26  2:13       ` Akinobu Mita
2006-01-26  2:13       ` Akinobu Mita
2006-01-26  2:13       ` Akinobu Mita
2006-01-26  2:19       ` Akinobu Mita
2006-01-25 20:02   ` Russell King
2006-01-25 20:02     ` Russell King
2006-01-25 20:02     ` Russell King
2006-01-25 20:02     ` Russell King
2006-01-25 20:02     ` Russell King
2006-01-25 20:59     ` Grant Grundler
2006-01-25 20:59       ` Grant Grundler
2006-01-26  3:27       ` Akinobu Mita
2006-01-26  3:27         ` Akinobu Mita
2006-01-26  3:29         ` [PATCH 1/12] generic *_bit() Akinobu Mita
2006-01-26  3:29           ` Akinobu Mita
2006-02-01 15:11           ` Chen, Kenneth W
2006-02-01 15:11             ` Chen, Kenneth W
2006-02-01 18:02             ` Christoph Hellwig
2006-02-01 18:02               ` Christoph Hellwig
2006-02-01 18:07           ` Chen, Kenneth W
2006-02-01 18:07             ` Chen, Kenneth W
2006-02-01 19:19             ` Russell King
2006-02-01 19:19               ` Russell King
2006-02-03 10:24               ` Geert Uytterhoeven
2006-02-03 10:24                 ` Geert Uytterhoeven
2006-02-03 10:27                 ` Russell King
2006-02-03 10:27                   ` Russell King
2006-02-01 19:39             ` Grant Grundler
2006-02-01 19:39               ` Grant Grundler
2006-02-02 22:43             ` Paul Mackerras
2006-02-02 22:43               ` Paul Mackerras
2006-02-01 19:25           ` Chen, Kenneth W
2006-02-01 19:25             ` Chen, Kenneth W
2006-02-01 19:35             ` Russell King
2006-02-01 19:35               ` Russell King
2006-02-01 21:41           ` Chen, Kenneth W
2006-02-01 21:41             ` Chen, Kenneth W
2006-02-01 22:09             ` Grant Grundler [this message]
2006-02-01 22:09               ` Grant Grundler
2006-02-01 22:49               ` Anton Altaparmakov
2006-02-01 22:49                 ` Anton Altaparmakov
2006-02-02  0:08                 ` Grant Grundler
2006-02-02  0:08                   ` Grant Grundler
2006-02-02  8:52                   ` Anton Altaparmakov
2006-02-02  8:52                     ` Anton Altaparmakov
2006-02-02 10:13                     ` Andreas Schwab
2006-02-02 10:13                       ` Andreas Schwab
2006-02-03 17:07           ` Luck, Tony
2006-02-03 17:07             ` Luck, Tony
2006-01-26  3:30         ` [PATCH 2/12] generic __ffs() Akinobu Mita
2006-01-26  3:30           ` Akinobu Mita
2006-01-26  3:31         ` [PATCH 3/12] generic ffz() Akinobu Mita
2006-01-26  3:31           ` Akinobu Mita
2006-01-26  8:21           ` Michael Tokarev
2006-01-26  8:21             ` Michael Tokarev
2006-01-27  6:39             ` [PATCH] parisc: add ()-pair in __ffs() Akinobu Mita
2006-01-27  6:39               ` Akinobu Mita
2006-01-26  3:32         ` [PATCH 4/12] generic fls() and fls64() Akinobu Mita
2006-01-26  3:32           ` Akinobu Mita
2006-01-26  3:33         ` [PATCH 5/12] generic find_{next,first}{,_zero}_bit() Akinobu Mita
2006-01-26  3:33           ` Akinobu Mita
2006-01-26  3:34         ` [PATCH 6/12] generic sched_find_first_bit() Akinobu Mita
2006-01-26  3:34           ` Akinobu Mita
2006-01-26  3:35         ` [PATCH 7/12] generic ffs() Akinobu Mita
2006-01-26  3:35           ` Akinobu Mita
2006-01-26  3:36         ` [PATCH 8/12] generic hweight{32,16,8}() Akinobu Mita
2006-01-26  3:36           ` Akinobu Mita
2006-01-26  7:12           ` Balbir Singh
2006-01-26  7:24             ` Balbir Singh
2006-01-26 10:04             ` Rutger Nijlunsing
2006-01-26 10:04               ` Rutger Nijlunsing
2006-01-27  4:55             ` Akinobu Mita
2006-01-27  4:55               ` Akinobu Mita
2006-01-27  5:40               ` Balbir Singh
2006-01-27  5:52                 ` Balbir Singh
2006-01-27  6:40                 ` Akinobu Mita
2006-01-27  6:40                   ` Akinobu Mita
2006-01-31 11:14                   ` Balbir Singh
2006-01-31 11:26                     ` Balbir Singh
2006-01-26 18:57           ` Bryan O'Sullivan
2006-01-26 18:57             ` Bryan O'Sullivan
2006-01-27  4:43             ` Akinobu Mita
2006-01-27  4:43               ` Akinobu Mita
2006-01-27  5:23               ` Bryan O'Sullivan
2006-01-27  5:23                 ` Bryan O'Sullivan
2006-01-31 16:49           ` linux
2006-01-31 16:49             ` linux
2006-01-31 18:14             ` Grant Grundler
2006-01-31 18:14               ` Grant Grundler
2006-02-02  9:34             ` Balbir Singh
2006-02-02  9:46               ` Balbir Singh
2006-01-26  3:36         ` [PATCH 9/12] generic hweight64() Akinobu Mita
2006-01-26  3:36           ` Akinobu Mita
2006-01-26  7:05           ` Balbir Singh
2006-01-26  7:17             ` Balbir Singh
2006-01-26  3:38         ` [PATCH 10/12] generic ext2_{set,clear,test,find_first_zero,find_next_zero}_bit() Akinobu Mita
2006-01-26  3:38           ` Akinobu Mita
2006-01-26  3:38         ` [PATCH 11/12] generic ext2_{set,clear}_bit_atomic() Akinobu Mita
2006-01-26  3:38           ` Akinobu Mita
2006-01-26  3:39         ` [PATCH 12/12] generic minix_{test,set,test_and_clear,test,find_first_zero}_bit() Akinobu Mita
2006-01-26  3:39           ` Akinobu Mita
2006-01-25 23:25     ` [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h Ian Molton
2006-01-25 23:25       ` Ian Molton
2006-01-26  0:06     ` Richard Henderson
2006-01-26  0:06       ` Richard Henderson
2006-01-26  4:34       ` Edgar Toernig
2006-01-26  4:34         ` Edgar Toernig
2006-01-26  4:34         ` Edgar Toernig
2006-01-26 17:30         ` Richard Henderson
2006-01-26 17:30           ` Richard Henderson
2006-01-26 17:30           ` Richard Henderson
2006-01-26  8:55       ` Russell King
2006-01-26  8:55         ` Russell King
2006-01-26 16:18         ` [parisc-linux] " Grant Grundler
2006-01-26 16:18           ` Grant Grundler
2006-01-26 16:18           ` Grant Grundler
2006-01-26 16:18           ` Grant Grundler
2006-01-26 16:30           ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of Nicolas Pitre
2006-01-26 16:30             ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h Nicolas Pitre
2006-01-26 16:30             ` Nicolas Pitre
2006-01-27  0:28             ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of John David Anglin
2006-01-27  0:28               ` John David Anglin
2006-01-27  0:28               ` John David Anglin
2006-01-27  0:28               ` John David Anglin
2006-01-27  0:28               ` John David Anglin
2006-01-26 16:40           ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h Russell King
2006-01-26 16:40             ` Russell King
2006-01-26 16:40             ` Russell King
2006-01-26 16:40             ` Russell King
2006-01-26 16:40             ` Russell King
2006-01-26 22:55             ` Grant Grundler
2006-01-26 23:04               ` Grant Grundler
2006-01-26 23:04               ` Grant Grundler
2006-01-26 22:55               ` Grant Grundler
2006-01-26 22:55               ` Grant Grundler
2006-01-26 23:03               ` Russell King
2006-01-26 23:03                 ` Russell King
2006-01-26 23:03                 ` Russell King
2006-01-29  7:12                 ` Stuart Brady
2006-01-29  7:12                   ` Stuart Brady
2006-01-30  4:03                   ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of David S. Miller
2006-01-30  4:03                     ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h David S. Miller
2006-01-30  4:03                     ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of David S. Miller
2006-01-30  4:03                     ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h David S. Miller
2006-01-30  4:03                     ` David S. Miller
2006-01-30 17:06                   ` Ralf Baechle
2006-01-30 17:06                     ` Ralf Baechle
2006-01-30 19:50                     ` Stuart Brady
2006-01-30 19:50                       ` Stuart Brady
2006-01-30 23:02                       ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of David S. Miller
2006-01-30 23:02                         ` [parisc-linux] Re: [PATCH 3/6] C-language equivalents of include/asm-*/bitops.h David S. Miller
2006-01-30 23:02                         ` David S. Miller
2006-01-27 12:51   ` Hirokazu Takata
2006-01-27 12:51     ` Hirokazu Takata
2006-01-27 12:51     ` Hirokazu Takata
2006-01-27 12:51     ` Hirokazu Takata
2006-01-27 12:51     ` Hirokazu Takata
2006-01-30  3:29     ` Akinobu Mita
2006-01-30  3:29       ` Akinobu Mita
2006-01-30  3:29       ` Akinobu Mita
2006-01-30  3:29       ` Akinobu Mita
2006-01-30  3:29       ` Akinobu Mita
2006-01-25 11:33 ` [PATCH 4/6] use include/asm-generic/bitops for each architecture Akinobu Mita
2006-01-26  1:49   ` Akinobu Mita
2006-01-26  1:49     ` Akinobu Mita
2006-01-26  1:49     ` Akinobu Mita
2006-01-26  1:49     ` Akinobu Mita
2006-01-26  1:49     ` Akinobu Mita
2006-01-26  2:37     ` Grant Grundler
2006-01-27 13:04     ` [PATCH 4/6] use include/asm-generic/bitops for each Hirokazu Takata
2006-01-27 13:04       ` [PATCH 4/6] use include/asm-generic/bitops for each architecture Hirokazu Takata
2006-01-27 13:04       ` [PATCH 4/6] use include/asm-generic/bitops for each Hirokazu Takata
2006-01-27 13:04       ` [PATCH 4/6] use include/asm-generic/bitops for each architecture Hirokazu Takata
2006-01-27 13:04       ` Hirokazu Takata
2006-01-30  3:15       ` Akinobu Mita
2006-01-30  3:15         ` Akinobu Mita
2006-01-30  3:15         ` Akinobu Mita
2006-01-30  3:15         ` Akinobu Mita
2006-01-30  3:15         ` Akinobu Mita
2006-01-25 11:34 ` [PATCH 5/6] fix warning on test_ti_thread_flag() Akinobu Mita
2006-01-25 11:34   ` Akinobu Mita
2006-01-25 11:34   ` Akinobu Mita
2006-01-25 11:34   ` Akinobu Mita
2006-01-25 11:34   ` Akinobu Mita
2006-01-25 12:28   ` Geert Uytterhoeven
2006-01-25 12:28     ` Geert Uytterhoeven
2006-01-25 12:28     ` Geert Uytterhoeven
2006-01-25 17:08   ` Chen, Kenneth W
2006-01-25 17:08     ` Chen, Kenneth W
2006-01-25 17:08     ` Chen, Kenneth W
2006-01-25 17:08     ` Chen, Kenneth W
2006-01-25 17:19     ` Geert Uytterhoeven
2006-01-25 17:19       ` Geert Uytterhoeven
2006-01-25 17:19       ` Geert Uytterhoeven
2006-01-25 20:02   ` Chen, Kenneth W
2006-01-25 20:02     ` Chen, Kenneth W
2006-01-25 20:02     ` Chen, Kenneth W
2006-01-25 20:02     ` Chen, Kenneth W
2006-01-26  3:50     ` Akinobu Mita
2006-01-26  3:50       ` Akinobu Mita
2006-01-26  3:50       ` Akinobu Mita
2006-01-26  3:50       ` Akinobu Mita
2006-01-26  4:12       ` Paul Mackerras
2006-01-26  4:12         ` Paul Mackerras
2006-01-26  4:12         ` Paul Mackerras
2006-01-26  4:12         ` Paul Mackerras
2006-01-25 22:28   ` Paul Mackerras
2006-01-25 22:28     ` Paul Mackerras
2006-01-25 22:28     ` Paul Mackerras
2006-01-25 22:28     ` Paul Mackerras
2006-01-25 22:28     ` Paul Mackerras
2006-01-25 22:28     ` Paul Mackerras
2006-01-26  0:04     ` David S. Miller
2006-01-26  0:04       ` David S. Miller
2006-01-26  0:04       ` David S. Miller
2006-01-26  0:04       ` David S. Miller
2006-01-26  0:04       ` David S. Miller
2006-01-25 11:35 ` [PATCH 6/6] remove unused generic bitops in include/linux/bitops.h Akinobu Mita
2006-01-25 11:35   ` Akinobu Mita
2006-01-25 11:35   ` Akinobu Mita
2006-01-25 11:35   ` Akinobu Mita
2006-01-25 11:35   ` Akinobu Mita

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=20060201220903.GE16471@esmail.cup.hp.com \
    --to=iod00d@hp.com \
    --cc=hch@infradead.org \
    --cc=kenneth.w.chen@intel.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mita@miraclelinux.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 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.