On Mon, Mar 10, 2014 at 7:20 PM, H. Peter Anvin <h...@zytor.com> wrote:
> Bool vs bitfield are orthogonal, at least under gcc, unless I'm completely
> out to sea. It is probably not a good idea to create a bitfield when it
> doesn't buy you anything, lest you generate rmw instructions when byte stores
> would do.
>
access to upper fields of sk_filter is not in critical path, therefore
my preference
is to save space.
In this case:
struct sk_filter {
atomic_t refcnt;
unsigned int len;
unsigned int len_ext;
bool or unsigned int:1 jited;
and the rest are pointers.
so either u32:1 or bool approach adds 4 bytes.
The reason I used bitfield is that I was expecting someone to complain
about overall size
increase and I can optimize it later into:
unsigned int len:15;
unsigned int len_ext:15;
unsigned int jited:1;
without touching arch/*/net/*jit files, since filter len fits.
Only lower part is cache sensitive, since 'insns/insns_ext' need to come close
enough to 'bpf_func', so that interpreter (called via SK_RUN_FILTER macro)
starts executing insns out of cache.
Thanks
Alexei
> On March 10, 2014 7:02:18 PM PDT, Linus Torvalds
> <torva...@linux-foundation.org> wrote:
>>On Mon, Mar 10, 2014 at 6:51 PM, David Miller <da...@davemloft.net>
>>wrote:
>>> From: Alexei Starovoitov <a...@plumgrid.com>
>>> Date: Sun, 9 Mar 2014 23:04:02 -0700
>>>
>>>> + unsigned int jited:1;
>>>
>>> The C language has a proper type for boolean states, please therefore
>>> use 'bool', true, and false.
>>
>>No, the C standard actually has no such thing.
>>
>>In a structure, a bitfield is actually better than bool, because it
>>takes only one bit. A "bool" takes at least a byte.
>>
>>Now, in this case it may not be an issue (looks like there are no
>>other uses that can use the better packing, so bit/byte/word is all
>>the same), but I really really want to make it clear that it is not at
>>all true that "bool" is somehow better than a single-bit bitfield. The
>>bitfield can pack *much* better, and I would actually say that it's
>>generally a *better* idea to use a bitfield, because you can much more
>>easily expand on it later by adding other bitfields.
>>
>>There are very few actual real advantages to "bool". The magic casting
>>behavior is arguably an advantage (the implicit cast in assigning to a
>>bitfield truncates to the low bits, the implicit cast on assignment to
>>"bool" does a test against zero), but is also quite arguably a
>>possible source of confusion and can cause problems down the line when
>>converting from bool to a bitfield (for the afore-mentioned packing
>>reasons).
>>
>>So please don't sell "bool" as some kind of panacea. It has at least
>>as many problems as it has advantages.
>>
>>I would generally suggest that people only use "bool" for function
>>return types, and absolutely nothing else. Seriously.
>>
>> Linus
>
> --
> Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
