On Wed, Sep 16, 2015 at 01:18:29PM -0400, Jeff Layton wrote: > On Mon, 14 Sep 2015 12:10:15 -0400 > "bfields@xxxxxxxxxxxx" <bfields@xxxxxxxxxxxx> wrote: > > > On Sat, Sep 12, 2015 at 06:24:54AM -0400, Jeff Layton wrote: > > > I don't think it matters, at least not on x86_64. bools and chars both > > > require a byte. pahole does show this adding a new hole, but that's > > > just because this brings the code up to 5 flags and the next field > > > (fh_pre_size) needs to be aligned. > > > > > > I do agree that replacing those other unsigned chars with bools is more > > > clear however. Maybe we should even replace them all with a single > > > unsigned int and use bitops to set flags in there. That would be more > > > space efficient now that we're at 5 flags. > > > > Makes sense to me.--b. > > I played around with this a little today, and it turns out not to make > a lot of difference. Here's what pahole says about the existing code > (once I moved fh_maxsize to snuggle up to fh_handle to plug a hole): ... > I used an unsigned long for fh_flags since we might as well. Making it > smaller just adds a hole in there since the compiler wants to align the > fh_pre_size. Moving it around doesn't help either as it just moves the > hole around. Note that this is x86_64. It might look different on a > 32-bit arch, but I doubt it really matters much in the big scheme of > things. > > Bruce, I'll send out the patches that change this if you like, but I'm > inclined to just leave this alone since it doesn't seem to have a > tangible benefit. Unless more flags are imminent I guess it's just a question of which is more readable. Arguably there's some value to making it more obvious that these are each just a bit. I'll accept your judgement on that question. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
