On Wed, 6 Feb 2019 at 13:43, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>
> On 6/02/19 2:00 PM, Ulf Hansson wrote:
> > + Adrian, Linus
> >
> > On Tue, 5 Feb 2019 at 17:53, Zachary Hays <zhays@xxxxxxxxxxx> wrote:
> >>
> >> The kblockd workqueue is created with the WQ_MEM_RECLAIM flag set.
> >> This generates a rescuer thread for that queue that will trigger when
> >> the CPU is under heavy load and collect the uncompleted work.
> >>
> >> In the case of mmc, this creates the possibility of a deadlock as
> >> other blk-mq work is also run on the same queue. For example:
> >>
> >> - worker 0 claims the mmc host
> >> - worker 1 attempts to claim the host
> >> - worker 0 schedules complete_work to release the host
> >> - rescuer thread is triggered after time-out and collects the dangling
> >> work
> >> - rescuer thread attempts to complete the work in order starting with
> >> claim host
> >> - the task to release host is now blocked by a task to claim it and
> >> will never be called
> >>
> >
> > Adrian, I need your help to understand more of this. The above
> > description doesn't add up to me.
> >
> > In principle, already when "worker 1 attempts to claim the host" as
> > described above, it should succeed and should *not* need to wait for
> > the host to be released. Right?
>
> If it is the same queue, then yes. Although in that case there is only 1
> work for the hw queue so there cannot be another worker. There could be
> another attempt to send a request directly, but that will not block - if the
> host controller is busy, BLK_STS_RESOURCE will be returned from ->queue_rq().
>
Right.
> >
> > The hole point with the commit 6c0cedd1ef95 ("mmc: core: Introduce
> > host claiming by context"), was to allow the mmc host to be
> > re-claimable for blk I/O requests, no matter from what worker/thread
> > the claim/release is done from.
> >
> > Is it not working as expected you think? What am I missing here?
>
> I assumed we were talking about a situation where there are multiple
> internal eMMC partitions each with their own disk and queue. In that case,
> a queue waits if there is another queue that is using the eMMC.
Of course! I totally forgot about this case, that is most certainly
what must be happening!
>
> We should clarify whether that is the scenario we are looking at. Zachary?
Yes, please.
Assuming this is the case, I would also prefer an updated changelog
that describe this scenario.
Adrian, thanks a lot for you help!
[...]
Kind regards
Uffe
