public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Dorfman <kdorfman@codeaurora.org>
To: Sergey Priporov <spriporov@gmail.com>
Cc: linux-mmc@vger.kernel.org, Maya Erez <merez@codeaurora.org>
Subject: Re: [RFC PATCH 00/11] [FS, MM, block,      MMC]: eMMC High Priority Interrupt Feature
Date: Wed, 09 Jan 2013 10:15:39 +0200	[thread overview]
Message-ID: <50ED272B.4000004@codeaurora.org> (raw)
In-Reply-To: <loom.20130108T185414-599@post.gmane.org>

Hello Sergey,

I'm working on the same flow - to reduce read latency hit (as a result 
of big aggregated writes). I plan to send all relevant patches to the 
mailing list soon and it will be great if you can test them on your system.

There are requirements for this flow is:
  - eMMC 4.5 supported by card (this means HPI)
  - host controller shoud implement stop request api (that is be able 
correctly stop DMA & all internal state and be ready for next read 
transaction.

Right now, please look at this patches as reference:

1. [RFC/PATCH 0/2] Handling urgent and new request notifications.
2. [RFC/PATCH 1/2] mmc: Urgent data request flow.

This is old changes, just for the solution overview.

Thanks,

> Hi Venkat,
>
> I was looking for some explanations of eMMC behavior in products we  are
> developing now and found your comments around eMMC here. Our observation
> shows
> that that eMMC performance vary significantly and depends on volume of
> data to
> write during time slot and temperature. After a heavy write test was run
> for
> some time for a good performance eMMC (showing 10-12MB/s of the write
> performance on big blocks) its write performance degraded to the 4-5MB/s.
> We even observed performance lowest level as 65KB/s!
> There are a lot of Write type of operations necessary into dedicated eMMC
> partition by requirements.
> The side effect is that long write operations block  Application UI to
> redraw
> the  views  because it requires Read operations.
> Visually we see “Blank Dark Screen” for few seconds and even ANRs. So
> HMI may
> help us.
>
> Question:  Did you finish research with HPI to try ?  Which type of eMMC
> did
> you use?
>
> P.S. We use TI BSP for OMAP3630 for Android
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  reply	other threads:[~2013-01-09  8:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-18  6:25 [RFC PATCH 00/11] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 01/11] fs: Add demand paging markers to filesystem Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 02/11] mm: Add page swapping markers to memory management Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 03/11] block: Add queue attributes to manage dpmg and swapin requests Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 04/11] block: Expedite DMPG and SWAPIN requests ahead of the queue Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 05/11] mmc: Add BKOPS field offsets Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 06/11] mmc: core: Helper function for finding preemptible command Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 07/11] mmc: core: add preemptibility tracking fields to mmc command Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 08/11] mmc: core: Add MMC abort interface Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 09/11] mmc: block: Detect HPI support in card and host controller Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 10/11] mmc: core: Utility function for mmc preemption sequence Venkatraman S
2012-04-18  6:25 ` [RFC PATCH 11/11] mmc: block: Implement HPI invocation and handling for foreground requests Venkatraman S
2012-05-15 18:24 ` [RFC PATCH 00/11] [FS, MM, block, MMC]: eMMC High Priority Interrupt Feature Konstantin Dorfman
2013-01-08 17:55   ` Sergey Priporov
2013-01-09  8:15     ` Konstantin Dorfman [this message]
2013-01-09 21:12       ` Sergey Priporov

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=50ED272B.4000004@codeaurora.org \
    --to=kdorfman@codeaurora.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=merez@codeaurora.org \
    --cc=spriporov@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox