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