All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kiwoong Kim" <kwmad.kim@samsung.com>
To: "'Ulf Hansson'" <ulf.hansson@linaro.org>
Cc: <linux-mmc@vger.kernel.org>
Subject: RE: About a possibility of long latency to claim host
Date: Wed, 10 Mar 2021 12:56:42 +0900	[thread overview]
Message-ID: <002401d71561$62112220$26336660$@samsung.com> (raw)
In-Reply-To: <CAPDyKFoEGp1CHo1OuTTeGqKkPG1Nke0k_rLBLSwmLH_BCcDDtA@mail.gmail.com>

> On Tue, 9 Mar 2021 at 14:07, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Tue, 9 Mar 2021 at 05:11, Kiwoong Kim <kwmad.kim@samsung.com> wrote:
> > >
> > > Dear All
> > >
> > > I want to discuss about this topic with you guys.
> > >
> > > There is an application to put many IO requests to a SD card right
> after completion of system resume.
> > > Current MMC stack invokes mmc_rescan asynchronously for
> PM_POST_SUSPEND.
> > > As reported to me, there could be a race between an IO thread and
> > > the kworker for mmc_rescan, especially when the application
> > > mentioned before is installed and the function of mmc_rescan is run
> later than expected For a series of IO requests, mmc_rescan, particularily
> at __mmc_claim_host called in mmc_sd_detect, didn't acquire a host for
> longer than expected.
> >
> > That's not a problem, in general.
> >
> > As long as the card is inserted and functional, the I/O operations
> > should be completed successfully. It doesn't matter if mmc_rescan() is
> > waiting to claim the host, as it's not important that it gets to run
> > as long as the card remains inserted/functional.
> >
> > >
> > > Below is the call stacks shown after the symptom happened and the
> system tried to enter into suspend again.
> > > In this case, mmc pm notifier is called with PM_SUSPEND_PREPARE, so it
> waits for completion or cancelling the work for mmc_rescan.
> > > For the latency, mobile users can see black screen for a long time
> sometimes, even with pushing a power button to wake up the system.
> >
> > I think I understand what you are saying, but please correct me if I am
> wrong.
> >
> > The I/O requests keep flowing into the blk queue even after
> > PM_SUSPEND_PREPARE has been fired, thus preventing the earlier
> > scheduled mmc_rescan() from claiming the host?
> >
> > This sounds quite reasonable that it could happen, at least
> > theoretically. Although, I am a bit surprised that nobody has reported
> > about this problem, until now. The design in the mmc core, has
> > remained unchanged in regards to this behaviour, for a very very long
> > time.
> >
> > Let me try to reproduce the problem, I will get back to you soon. In
> > the meantime, I would also appreciate it if you could share, more
> > exactly, how to trigger this problem at your side.
> 
> I have managed to reproduce the problem!  Wow, I wonder how this could
> have slipped through without anybody reporting about this, until now.
> So, thanks for bringing this to my attention!
> 
> My rough guess is that SD cards, used in these kinds of configurations
> (Android), are actually set to non removable. This would prevent
> mmc_rescan() from claiming the host.
> 
> In any case, this needs to be fixed properly. I will continue to work on a
> solution and get back to you with a patch. 

Okay and I'll also thing about its fix.

Thanks.
Kiwoong Kim

> 
> [...]
> 
> Kind regards
> Uffe


  reply	other threads:[~2021-03-10  3:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210309041059epcas2p49567b092c8d82bb80aa76ad26f8d212b@epcas2p4.samsung.com>
2021-03-09  4:10 ` About a possibility of long latency to claim host Kiwoong Kim
2021-03-09 13:07   ` Ulf Hansson
2021-03-09 17:21     ` Ulf Hansson
2021-03-10  3:56       ` Kiwoong Kim [this message]
2021-03-10  3:55     ` Kiwoong Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='002401d71561$62112220$26336660$@samsung.com' \
    --to=kwmad.kim@samsung.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.