Re: [PATCH] mmc: block: handle complete_work on separate workqueue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux