Messages in this thread | | | Date | Wed, 1 Feb 2006 22:49:08 +0000 (GMT) | From | Anton Altaparmakov <> | Subject | Re: [PATCH 1/12] generic *_bit() |
| |
On Wed, 1 Feb 2006, Grant Grundler wrote: > 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.
Err, searching by anything other than bytes is useless for a file system driver. Otherwise you get all sorts of disgustingly horrible allocation patterns depending on the endianness of the machine...
Best regards,
Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |