Thread (6 messages) 6 messages, 3 authors, 2017-12-02

Re: [PATCH] block, bfq: remove batches of confusing ifdefs

From: Jens Axboe <axboe@kernel.dk>
Date: 2017-12-02 16:06:26
Also in: lkml

On 12/02/2017 03:04 AM, Paolo Valente wrote:
quoted
Il giorno 30 nov 2017, alle ore 22:21, Jens Axboe [off-list ref] ha scritto:

On 11/28/2017 02:37 AM, Paolo Valente wrote:
quoted
Commit a33801e8b473 ("block, bfq: move debug blkio stats behind
CONFIG_DEBUG_BLK_CGROUP") introduced two batches of confusing ifdefs:
one reported in [1], plus a similar one in another function. This
commit removes both batches, in the way suggested in [1].
Some comments below.
quoted
+static inline void bfq_update_dispatch_stats(struct request *rq,
+					     spinlock_t *queue_lock,
+					     struct bfq_queue *in_serv_queue,
+					     bool idle_timer_disabled)
+{
Don't pass in the queue lock. The normal convention is to pass in the
queue, thus making this:

static void bfq_update_dispatch_stats(struct request_queue *q,
				      struct request *rq,
				      struct bfq_queue *in_serv_queue,
				      bool idle_timer_disabled)
Ok, thanks.  One question, just to try to learn, if you have time and
patience for a brief explanation.  Was this convention originated by
some rationale?  My concern is that bfq_update_dispatch_stats works on
no field of q but the lock, and this fact would have been made
explicit by passing only that exact field.
When you just pass in a lock, nobody knows what that lock is without
looking at the caller. If you pass in the queue, it's apparent
what is being locked.
quoted
which also gets rid of the inline. In general, never inline anything.
The compiler should figure it out for you. This function is way too big
to inline, plus the cost of what it's doing completely dwarfes function
call overhead.
Actually, I did so because of Linus' suggestion in [1]: "So for
example, the functions that can go away should obviously be inline
functions so that you don't end up having the compiler generate the
arguments and the call to an empty function body ..."

Maybe I misinterpreted his suggestion, and he meant that the function
should be designed in such a way to be (almost) certainly considered
inline by the compiler?
You can do that for the empty version, don't do it for the non-empty
version. That will go away, the other one will not.

-- 
Jens Axboe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help