On Wed, May 9, 2012 at 6:15 AM, Minchan Kim [off-list ref] wrote:

On 05/09/2012 01:31 AM, S, Venkatraman wrote:

quoted

On Tue, May 8, 2012 at 1:16 PM, Minchan Kim [off-list ref] wrote:

quoted

On 05/03/2012 11:22 PM, Venkatraman S wrote:

quoted

Standard eMMC (Embedded MultiMedia Card) specification expects to execute
one request at a time. If some requests are more important than others, they
can't be aborted while the flash procedure is in progress.

New versions of the eMMC standard (4.41 and above) specfies a feature
called High Priority Interrupt (HPI). This enables an ongoing transaction
to be aborted using a special command (HPI command) so that the card is ready
to receive new commands immediately. Then the new request can be submitted
to the card, and optionally the interrupted command can be resumed again.

Some restrictions exist on when and how the command can be used. For example,
only write and write-like commands (ERASE) can be preempted, and the urgent
request must be a read.

In order to support this in software,
a) At the top level, some policy decisions have to be made on what is
worth preempting for.
      This implementation uses the demand paging requests and swap
read requests as potential reads worth preempting an ongoing long write.
      This is expected to provide improved responsiveness for smarphones
with multitasking capabilities - example would be launch a email application
while a video capture session (which causes long writes) is ongoing.

Do you have a number to prove it's really big effective?

What type of benchmarks would be appropriate to post ?
As you know, the response time of a card would vary depending on
whether the flash device
has enough empty blocks to write into and doesn't have to resort to GC during
write requests.
Macro benchmarks like iozone etc would be inappropriate here, as they won't show
the latency effects of individual write requests hung up doing page
reclaim, which happens
once in a while.

We don't have such special benchmark so you need time to think how to prove it.
IMHO, you can use run-many-x-apps.sh which checks elapsed time to activate programs
by posting by Wu long time ago.

http://www.spinics.net/lists/linux-mm/msg09653.html

Of course, your eMMC is used above 80~90% for triggering GC stress and
your memory should be used up by dirty pages to happen reclaim.

quoted

quoted

What I have a concern is when we got low memory situation.
Then, writing speed for page reclaim is important for response.
If we allow read preempt write and write is delay, it means read path takes longer time to
get a empty buffer pages in reclaim. In such case, it couldn't be good.

I agree. But when writes are delayed anyway as it exceeds
hpi_time_threshold (the window
available for invoking HPI), it means that the device is in GC mode
and either read or write
could be equally delayed.  Note that even in case of interrupting a
write, a single block write
(which usually is too short to be interrupted, as designed) is
sufficient for doing a page reclaim,
and further write requests (including multiblock) would not be subject
to HPI, as they will
complete within the average time.

My point is that it would be better for read to not preempt write-for-page_reclaim.
And we can identify it by PG_reclaim. You can get the idea.

Anyway, HPI is only feature of a device of many storages and you are requiring modification
of generic layers although it's not big. So for getting justification and attracting many
core guys(MM,FS,BLOCK), you should provide data at least.

Hi Kim,
 Apologies for a delayed response. I am studying your suggestions and
will get back with
some changes and also some profiling data.
Regards,
Venkat.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html