Hi , Any update on this patch ? On Wed, Jan 11, 2012 at 4:57 PM, Shashidhar Hiremath <shashidharh@xxxxxxxxxxxxxxx> wrote: > Hi James, > Sorry for delay in getting the performance numbers since there was > some issue with the Hardware. > Even though the Dual Buffer Patch does not improve the performance > considerably for Read operations, but for the write operations, I > found the improvement in speed of upto 200 KiB/s. > Please find the numbers for the tests with considerable improvement as below :- > > Best Case Write Test:- > Chain Mode:- > Transfer of 1 x 256 sectors (1 x 128 KiB) took 0.034517837 seconds > (3797 kB/s, 3708 KiB/s, 28.97 IOPS, sg_len 32) > > Dual Buffer Mode:- > Transfer of 1 x 256 sectors (1 x 128 KiB) took 0.033325325 seconds > (3933 kB/s, 3840 KiB/s, 30.00 IOPS, sg_len 32 > > > Best Case Write Test for scattered Memory:- > Chain Mode:- > Transfer of 1 x 256 sectors (1 x 128 KiB) took 0.035052520 seconds > (3739 kB/s, 3651 KiB/s, 28.52 IOPS, sg_len 32 > > Dual Buffer Mode:- > Transfer of 1 x 256 sectors (1 x 128 KiB) took 0.033113106 seconds > (3958 kB/s, 3865 KiB/s, 30.19 IOPS, sg_len 32) > > > Single Write by Transfer Size:- > Chain Mode:- > Transfer of 1 x 256 sectors (1 x 128 KiB) took 0.034675358 seconds > (3779 kB/s, 3691 KiB/s, 28.83 IOPS, sg_len 32) > > Dual Buffer Mode:- > Transfer of 1 x 256 sectors (1 x 128 KiB) took 0.033575460 seconds > (3903 kB/s, 3812 KiB/s, 29.78 IOPS, sg_len 32) > > Write performance blocking req 1 to 512 sg elems:- > Chain Mode:- > Transfer of 1024 x 256 sectors (1024 x 128 KiB) took 38.029996867 > seconds (3529 kB/s, 3446 KiB/s, 26.92 IOPS, sg_len 256) > > Dual Buffer:- > Transfer of 1024 x 256 sectors (1024 x 128 KiB) took 37.489874739 > seconds (3580 kB/s, 3496 KiB/s, 27.31 IOPS, sg_len 256) > > Write performance non-blocking req 1 to 512 sg elems:- > Chain Mode:- > Transfer of 1024 x 256 sectors (1024 x 128 KiB) took 38.057999074 > seconds (3526 kB/s, 3444 KiB/s, 26.90 IOPS, sg_len 256 > Dual Buffer:- > Transfer of 1024 x 256 sectors (1024 x 128 KiB) took 37.489499346 > seconds (3580 kB/s, 3496 KiB/s, 27.31 IOPS, sg_len 256 > > > On Sat, Nov 19, 2011 at 7:04 AM, James Hogan <james@xxxxxxxxxxxxx> wrote: >> >> Hi Shashidhar, >> >> On Mon, Nov 14, 2011 at 09:32:25PM +0530, Shashidhar Hiremath wrote: >> > Hi Will, >> > >> > Just following up since i did not see any response from you on my >> > earlier mail.. In previous mail, im not sure whether i gave you enough >> > context/background.. So here it goes (apologies in advance if this >> > turns out to be a lengthy mail...): >> > >> > 1>At Vayavya Labs, our work is to make sure that drivers for SNPS >> > designware IP is available in kernel.org. One of the >> > mandates/requirements from SNPS is that the driver submitted to >> > kernel.org should support all the features/configurations of the IP. >> > The bigger picture being that once this is done, SNPS customers dont >> > have to write code for any specific feature/configuration since it is >> > already available in the driver and they can start using it >> > immediately... >> > 2>As such, it is required that code for dual descriptors be also >> > present in the driver submitted to kernel.org.. In future there, there >> > could be some person wanting to use this feature of the IP.. >> > 3>Also note that in kconfig, there does not have to be a choice >> > between this mode and chained mode since the default will always be >> > chained mode. STM Ethernet MAC driver already has such a kind of >> > support.. If this is not acceptable, do you feel the code should be >> > wrapped in some totally different preprocessor directive with comments >> > in the driver explaining the same? >> > 4>With regards to your points on performance, I am open to look at it >> > and see where we can make improvements in the driver (if any... if its >> > a hardware thing, there is not much we can do) >> >> Can I suggest you try running mmc_test with and without the dual >> descriptor mode. It has a bunch of performance tests in it. >> >> Cheers >> James >> >> > >> > Do let me know your views. >> > >> > best regards >> > --Shashidhar Hiremath >> > >> > On Fri, Nov 4, 2011 at 12:36 PM, Shashidhar Hiremath >> > <shashidharh@xxxxxxxxxxxxxxx> wrote: >> > > Hi Will, >> > > I agree with you that it should not be merged unless it improves >> > > the performance. But I still feel that there might be some reason for >> > > which the IP Vendor has provided an additional feature. So will this >> > > not be a good feature to have as it will help in IP Validation for >> > > different modes. >> > > As far as the Kconfig option is concerned, the user need not always >> > > modify it since the default case will still be Chained Mode. Also Such >> > > Kconfig options for selecting mode is already used for stmmac >> > > Ethernet Drivers. >> > > >> > > On Thu, Nov 3, 2011 at 8:48 PM, Will Newton <will.newton@xxxxxxxxx> wrote: >> > >> On Thu, Nov 3, 2011 at 12:35 PM, Chris Ball <cjb@xxxxxxxxxx> wrote: >> > >>> Hi, >> > >>> >> > >>> On Thu, Nov 03 2011, Shashidhar Hiremath wrote: >> > >>>> Hi Chris, >> > >>>> Can this patch be accepted by criteria that its an additional >> > >>>> feature supported by the hardware and hence good to have the support >> > >>>> in the driver.Also note the patch has been tested. >> > >>> >> > >>> I think Will and James should make the call on that. >> > >>> >> > >>> My own opinion is that it's not usually a good idea to merge code that >> > >>> increases complexity for no performance gain; if the feature is actually >> > >>> important, someone should find a way to finish it and measure a >> > >>> performance gain (the gain can be in any of bandwidth, memory, or >> > >>> lower CPU utilization) with it, to prove that the change is worthwhile. >> > >> >> > >> I'm inclined to agree. I don't want to feel like I am blocking >> > >> inclusion of anyone's hard work, but unless there is a clear advantage >> > >> for one option over the other I can't see a good reason for merging >> > >> it. At present it adds a question to the Kconfig that is pretty much >> > >> impossible for the user to answer (do I turn this feature on or off? >> > >> what is the advantage of choosing each option?). >> > >> >> > > >> > > >> > > >> > > -- >> > > regards, >> > > Shashidhar Hiremath >> > > >> > >> > >> > >> > -- >> > regards, >> > Shashidhar Hiremath >> > -- >> > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> > the body of a message to majordomo@xxxxxxxxxxxxxxx >> > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > -- > regards, > Shashidhar Hiremath -- regards, Shashidhar Hiremath -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
