linux-kernel - Re: [PATCH] cfq-iosched: simplify prio-unboost code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Oct 2009 18:12:35 +0100
From:	Corrado Zoccolo <czoccolo@...il.com>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	Linux-Kernel <linux-kernel@...r.kernel.org>,
	Jeff Moyer <jmoyer@...hat.com>
Subject: Re: [PATCH] cfq-iosched: simplify prio-unboost code

On Thu, Oct 29, 2009 at 2:19 PM, Jens Axboe <jens.axboe@...cle.com> wrote:
> On Mon, Oct 26 2009, Corrado Zoccolo wrote:
>> Eliminate redundant checks.
>>
>> Signed-off-by: Corrado Zoccolo <czoccolo@...il.com>
>> ---
>>  block/cfq-iosched.c |    8 +++-----
>>  1 files changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
>> index 6e9b395..244bc8a 100644
>> --- a/block/cfq-iosched.c
>> +++ b/block/cfq-iosched.c
>> @@ -2611,12 +2611,10 @@ static void cfq_prio_boost(struct cfq_queue *cfqq)
>>                       cfqq->ioprio = IOPRIO_NORM;
>>       } else {
>>               /*
>> -              * check if we need to unboost the queue
>> +              * unboost the queue (if needed)
>>                */
>> -             if (cfqq->ioprio_class != cfqq->org_ioprio_class)
>> -                     cfqq->ioprio_class = cfqq->org_ioprio_class;
>> -             if (cfqq->ioprio != cfqq->org_ioprio)
>> -                     cfqq->ioprio = cfqq->org_ioprio;
>> +             cfqq->ioprio_class = cfqq->org_ioprio_class;
>> +             cfqq->ioprio = cfqq->org_ioprio;
>>       }
>
> Not sure I see much gain in that, the previous code makes it explicit
> that it may not be different and avoid dirtying cfqq if it isn't.

>From readability p.o.v., it is simpler to understand the direct assignment.
The comment says that they might already be equal, but the code states
clearly what is the final state, i.e. they will surely be equal at the
end-

Moreover, using two branches to avoid dirtying a cache line is not a
win performance-wise, given the penalty on mispredicted branches, and
the fact that the interval between two executions of this code is
large, so the branch predictor entries for those would be already
replaced by userspace ones.

If on some exotic MP hardware dirtying a cache line could be very
expensive, a similar check could be done in hardware, and it would be
more efficient, in fact it could distinguish the 2 cases:
* we already have the shared cache line locally -> we can compare the
value and absorb the write if it doesn't change
* we don't have the cache line locally -> we acquire the cache line in
exclusive mode, so we can do the write directly (on the contrary, the
previous code would first acquire the cache line as shared, and if
necessary, upgrade it to exclusive, possibly increasing the traffic).

Corrado

>
> --
> Jens Axboe
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/