Re: [RFC PATCH] request: teach the device more intelligent

[Kyungmin Park]

On Thu, Aug 11, 2011 at 11:20 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> On Thu, Aug 11, 2011 at 09:36:04AM +0900, Kyungmin Park wrote:
>
> [...]
>> No, no need to consistent. the context id id only valid when several
>> requests are request the I/O simultaneously
>> e.g.,
>> App1 requests A, B, C, D, ...
>> App2 requests a, b, c, d, ...
>> App2 requests 1, 2, 3, 4, 5, ...
>> with following order, A, B, a, 1, C, b, 2, ...
>>
>> The current eMMC can't handle these operation.
>>
>> Instead using context, it can teach the these operation comes from
>> using context ID. and finally can place the request in-order at card
>> internally.
>>
>> Open Context ID operation, perform I/O with context Id, ...., and
>> Close Context ID operation until queue is empty.
>
> Hi Kyungmin,
>
> So once we have context information, we want to process all the requests
> from the same context together? IOW, we expect that driver will have
> multiple requests in flight from various context and it will batch the
> requests from same context together?
It's current implementation. Actually there's no context until eMMC v4.41.
After eMMC v4.5. introduce the context and handle it efficiently if
context is provided from host
>
> How does that help? Is it something related to seeking? If yes, then just
> setting the rotational=1 should help as CFQ will sequence all the
> sequential IO where it can. For random IO, anyway optimization will not
> help. May be it is about something else which I am completely missing.
> Some details here will help.
No, it's dependent on firmware implementation at each vendor. but some
mixed workload, several programs requests the sequential write, and
one or two random write, it can assign the blocks one for sequential,
another for ramdon. don't mix it if context is provided.

Thank you,
Kyungmin Park
>
> Thanks
> Vivek
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/