Re: [PATCH] omap_hsmmc: Reduce max_segs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 21, 2017 at 10:16 AM, Ravikumar <rk@xxxxxx> wrote:

Hi Ravikumar,

> On Wednesday 21 June 2017 02:02 PM, Tony Lindgren wrote:
>>
>> * Will Newton <will.newton@xxxxxxxxx> [170621 01:18]:
>>>
>>> On Wed, Jun 21, 2017 at 7:24 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
>>>
>>> Hi Tony,
>>>
>>>> * Will Newton <will.newton@xxxxxxxxx> [170620 05:39]:
>>>>>
>>>>> Just adding a few people to CC. I'd love to get some feedback as to
>>>>> whether this patch makes sense or not.
>>>>>
>>>>> On Mon, Jun 19, 2017 at 10:36 AM, Will Newton <will.newton@xxxxxxxxx>
>>>>> wrote:
>>>>>>
>>>>>> Reduce max_segs to a value that allows allocation of an entire
>>>>>> descriptor list within a single page. This avoids doing a
>>>>>> higher order GFP_ATOMIC allocation when setting up a transfer
>>>>>> which can potentially fail and lead to I/O failures.
>>>>
>>>> I recall we only ever have few SG entries so if there is no performance
>>>> impact I see no reason to lower it to save memory. Care to check
>>>> if that's the case still?
>>>
>>> I have been seeing allocation failures in edma_prep_slave_sg
>>> allocating the descriptor list of order 3, which from my rough
>>> calculations is an sg_len of ~800. The memory usage itself doesn't
>>> seem like a problem but doing a GFP_ATOMIC allocation of higher order
>>> under I/O load seems like it is always going to cause problems.
>
> max_segs= 64  looks like a sensible value to me for edma/sdma, with each
> param set ~40Bytes - this will ensure to fit in a single page.
> IIRC, edma splits the list at 20. MAX_NR_SEGS set to 20 in edma.c. So,
> having a bigger number *may not* guarantee a proportional increase
> in throughput.
>
>> OK
>>
>>> I'm not an expert on this code but it looks like the scatterlist is
>>> created from the queue so if the queue gets full we can get a very
>>> large scatterlist. The current value of 1024 seems to be something of
>>> an outlier:
>
> When using ADMA, since you allocate the table only once during probe,
> there'll be no alloc calls at a later time.
> And increase in number of sg entries would increase efficiency. I've seen
> as many as 290-300 sg entries being used during file-system init/mount. So,
> for ADMA, I would say at least max_segs = 512 is a better option since
> descriptor size is 8B,
> would still fit in a page.
> You can over-wirte it under  "if (host->adma)"

I can't find this member in struct mmc_host on master, is there
somewhere else I should be looking?

Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux