On 24/10/17 10:39, Ulf Hansson wrote:
> [...]
>
>>> However, you have completely ignored mine, Linus and Bartlomiej's
>>> comments about that we want the blkmq port being a separate patch(es)
>>> and then make the CMDQ patches on top. This worries me, because it
>>> seems like our messages don't r
[...]
>> However, you have completely ignored mine, Linus and Bartlomiej's
>> comments about that we want the blkmq port being a separate patch(es)
>> and then make the CMDQ patches on top. This worries me, because it
>> seems like our messages don't reach you.
>
> Rubbish! I gave a very good rea
On 24/10/17 08:37, Ulf Hansson wrote:
> + Bartlomiej
>
> [...]
>
>> So my conclusion is, let's start a as you suggested, by not completing
>> the request in ->done() as to maintain existing behavior. Then we can
>> address optimizations on top, which very likely will involve doing
>>>
+ Bartlomiej
[...]
> So my conclusion is, let's start a as you suggested, by not completing
> the request in ->done() as to maintain existing behavior. Then we can
> address optimizations on top, which very likely will involve doing
> changes to host drivers as well.
Hav
On 20/10/17 15:30, Adrian Hunter wrote:
> On 19/10/17 14:44, Adrian Hunter wrote:
>> On 18/10/17 09:16, Adrian Hunter wrote:
>>> On 11/10/17 16:58, Ulf Hansson wrote:
On 11 October 2017 at 14:58, Adrian Hunter wrote:
> On 11/10/17 15:13, Ulf Hansson wrote:
>> On 10 October 2017 at 15:
On 19/10/17 14:44, Adrian Hunter wrote:
> On 18/10/17 09:16, Adrian Hunter wrote:
>> On 11/10/17 16:58, Ulf Hansson wrote:
>>> On 11 October 2017 at 14:58, Adrian Hunter wrote:
On 11/10/17 15:13, Ulf Hansson wrote:
> On 10 October 2017 at 15:31, Adrian Hunter
> wrote:
>> On 10/1
On 18/10/17 09:16, Adrian Hunter wrote:
> On 11/10/17 16:58, Ulf Hansson wrote:
>> On 11 October 2017 at 14:58, Adrian Hunter wrote:
>>> On 11/10/17 15:13, Ulf Hansson wrote:
On 10 October 2017 at 15:31, Adrian Hunter wrote:
> On 10/10/17 16:08, Ulf Hansson wrote:
>> [...]
>>
>>>
On 11/10/17 16:58, Ulf Hansson wrote:
> On 11 October 2017 at 14:58, Adrian Hunter wrote:
>> On 11/10/17 15:13, Ulf Hansson wrote:
>>> On 10 October 2017 at 15:31, Adrian Hunter wrote:
On 10/10/17 16:08, Ulf Hansson wrote:
> [...]
>
>
> I have also run some test on my
On 11/10/17 16:58, Ulf Hansson wrote:
> On 11 October 2017 at 14:58, Adrian Hunter wrote:
>> On 11/10/17 15:13, Ulf Hansson wrote:
>>> On 10 October 2017 at 15:31, Adrian Hunter wrote:
On 10/10/17 16:08, Ulf Hansson wrote:
> [...]
>
>
> I have also run some test on my
On 12 October 2017 at 10:08, Linus Walleij wrote:
> On Wed, Oct 11, 2017 at 3:58 PM, Ulf Hansson wrote:
>
>> Actually completing the request in the ->done callback, may still be
>> possible, because in principle it only needs to inform the other
>> prepared request that it may start, before it co
On Wed, Oct 11, 2017 at 3:58 PM, Ulf Hansson wrote:
> Actually completing the request in the ->done callback, may still be
> possible, because in principle it only needs to inform the other
> prepared request that it may start, before it continues to post
> process/completes the current one.
I t
On 11 October 2017 at 14:58, Adrian Hunter wrote:
> On 11/10/17 15:13, Ulf Hansson wrote:
>> On 10 October 2017 at 15:31, Adrian Hunter wrote:
>>> On 10/10/17 16:08, Ulf Hansson wrote:
[...]
I have also run some test on my ux500 board and enabling the blkmq
pa
On 11/10/17 15:13, Ulf Hansson wrote:
> On 10 October 2017 at 15:31, Adrian Hunter wrote:
>> On 10/10/17 16:08, Ulf Hansson wrote:
>>> [...]
>>>
>>>
>>> I have also run some test on my ux500 board and enabling the blkmq
>>> path via the new MMC Kconfig option. My idea was to run some i
On 10 October 2017 at 15:31, Adrian Hunter wrote:
> On 10/10/17 16:08, Ulf Hansson wrote:
>> [...]
>>
>>
>> I have also run some test on my ux500 board and enabling the blkmq
>> path via the new MMC Kconfig option. My idea was to run some iozone
>> comparisons between the legacy pa
On 10/10/17 16:08, Ulf Hansson wrote:
> [...]
>
>
> I have also run some test on my ux500 board and enabling the blkmq
> path via the new MMC Kconfig option. My idea was to run some iozone
> comparisons between the legacy path and the new blkmq path, but I just
> couldn't get t
[...]
I have also run some test on my ux500 board and enabling the blkmq
path via the new MMC Kconfig option. My idea was to run some iozone
comparisons between the legacy path and the new blkmq path, but I just
couldn't get to that point because of the following errors.
>
On 10/10/17 15:12, Ulf Hansson wrote:
> On 21 September 2017 at 11:44, Adrian Hunter wrote:
>> On 21/09/17 12:01, Ulf Hansson wrote:
>>> On 13 September 2017 at 13:40, Adrian Hunter
>>> wrote:
Hi
Here is V8 of the hardware command queue patches without the software
command qu
On 21 September 2017 at 11:44, Adrian Hunter wrote:
> On 21/09/17 12:01, Ulf Hansson wrote:
>> On 13 September 2017 at 13:40, Adrian Hunter wrote:
>>> Hi
>>>
>>> Here is V8 of the hardware command queue patches without the software
>>> command queue patches, now using blk-mq and now with blk-mq s
On Wed, Sep 13, 2017 at 02:40:00PM +0300, Adrian Hunter wrote:
> Non-CQE blk-mq showed a 3% decrease in sequential read performance. This
> seemed to be coming from the inferior latency of running work items compared
> with a dedicated thread. Hacking blk-mq workqueue to be unbound reduced the
>
On 21/09/17 12:01, Ulf Hansson wrote:
> On 13 September 2017 at 13:40, Adrian Hunter wrote:
>> Hi
>>
>> Here is V8 of the hardware command queue patches without the software
>> command queue patches, now using blk-mq and now with blk-mq support for
>> non-CQE I/O.
>>
>> After the unacceptable deba
On 13 September 2017 at 13:40, Adrian Hunter wrote:
> Hi
>
> Here is V8 of the hardware command queue patches without the software
> command queue patches, now using blk-mq and now with blk-mq support for
> non-CQE I/O.
>
> After the unacceptable debacle of the last release cycle, I expect an
> im
21 matches
Mail list logo
