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]
Message-ID: <b4a0fd3c-422e-2d23-bd8c-74bb0325b4fb@fb.com>
Date:   Tue, 13 Dec 2016 14:51:27 -0700
From:   Jens Axboe <axboe@...com>
To:     Paolo Valente <paolo.valente@...aro.org>
CC:     <linux-block@...r.kernel.org>,
        Linux-Kernal <linux-kernel@...r.kernel.org>, <osandov@...com>
Subject: Re: [PATCHSET/RFC v2] blk-mq scheduling framework

On 12/13/2016 09:28 AM, Jens Axboe wrote:
>>> No worries, ask away if you have questions. As you might have seen, it's
>>> still a little bit of a moving target, but it's getting closer every
>>> day. I'll post a v3 later today hopefully that will be a good fix point
>>> for you. I'll need to add the io context setup etc, that's not there
>>> yet, as only cfq/bfq uses that.
>>>
>>
>> You anticipated the question that was worrying me more, how to handle
>> iocontexts :) I'll go on studying your patches while waiting for this
>> (last, right?) missing piece for bfq.
> 
> It's the last missing larger piece. We probably have a few hooks that
> BFQ/CFQ currently uses that aren't wired up yet in the elevator_ops for
> mq, so you'll probably have to do those as you go. I can take a look,
> but I would prefer if they be done one a as-needed basis. Perhaps we can
> get rid of some of them.

The current 'blk-mq-sched' branch has support for getting the IO
contexts setup, and assigned to requests. Only works off the task
io_context for now, we ignore anything set in the bio. But that's a
minor thing, generally it should work for you.

Note that the mq ops have different naming than the classic elevator
ops. For instance, the set_request/put_request are
get_rq_priv/put_rq_priv instead. Others are different as well. In
general, refer to mq-deadline.c for how the hooks work and you can
compare with deadline-iosched.c, since they are still very close.

Note that the io context linking uses the embedded queue lock,
q->queue_lock, whereas for other things you are free to use a lock
embedded in the your elevator data. Again, refer to mq-deadline, it uses
dd->lock to protect the hash/rbtree. If mq-deadline used io contexts, it
would manage those behind q->queue_lock.

-- 
Jens Axboe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ