On 5/18/26 13:22, Christian König wrote:
On 5/18/26 12:29, Pavel Begunkov wrote:
On 5/13/26 09:19, Christoph Hellwig wrote:
+ if (!bio_flagged(bio_src, BIO_DMABUF_MAP)) {
+ bio->bi_io_vec = bio_src->bi_io_vec;
+ } else {
+ bio->dmabuf_map = bio_src->dmabuf_map;
+ bio_set_flag(bio, BIO_DMABUF_MAP);
+ }
This is backwards, please avoid pointless negations:
I can flip it, but compilers tend to prefer the true branch. E.g. this
if (cond) A; else B;
C;
can get compiled into:
jmpcc cond B
A: ...
C:
return;
B: ...
jmp C;
When that is really a performance critical path then you can use the likely()
and unlikely() macros to give the compiler the hint which one to prefer.
That might be more penalising than placing them in the right order,
and it might be fine as it's new and all that, but it's not a clear
cut as it's definitely not created to be a slow path. TBH, not sure
why we're bike shedding such things, is it somewhere in the code
style?
What could be useful is to have the true path for the more common and the false
path for the less common case for documentation purposes, but in that case I
would expected some code comments as well.
What kind of comment are you thinking about? A "this is not a likely
path" type of comment before each mention of the flag is usually not
very useful.
--
Pavel Begunkov
