On 6/4/13 12:25 AM, "Andy Shevchenko" <andy.shevche...@gmail.com> wrote:
>On Tue, Jun 4, 2013 at 2:29 AM, Jon Mason <jon.ma...@intel.com> wrote: >> On Fri, May 31, 2013 at 11:22:10AM +0300, Andy Shevchenko wrote: >>> On Fri, May 17, 2013 at 8:54 PM, Jon Mason <jon.ma...@intel.com> wrote: >>> > dmatest would create a thread to stress XOR and PQ, if the >>>capability is >>> > present in the hardware. Add the ability to disable XOR and PQ by >>> > disabling it if *_sources are set to zero. >>> >>> Sorry, didn't comment this earlier. >>> >>> Those threads are independent including MEMCPY stuff. >>> I think it's better to have one additional parameter let's say >>> type_of_test where you can set >>> 1 for MEMCPY >>> 2 for XOR >>> 4 for PQ >>> >>> Share this parameter via debugfs and use 0x07 as default value. >>> I doubt we need this as a module parameter. >> >> This is using the existing module parameter, so there is nothing new >> added. > >That's why it's a bit confusing. User can more easily forget the >'magic' numbers. And I see no reason to prevent user to enter 0 as a >number of sources. Well, source counts less than 2 are invalid for these operations, but that is besides the point. >Moreover, your patch doesn't cover the case when user doesn't want to >run MEMCPY thread. Yes, this is what I wanted to point out. If we're adding per operation type selection, might as well enable memcpy to be controlled too. Especially if we just use a bitmap_and() with the dma_cap_mask() to pick which tests to run. Might also encourage some slave-op test types to be added as well. > >> Since the testing is started immediately upon module >> insertion, > >It used to be so, but nowadays it's true only when dmatest is compiled in. >If someone wants to compile in that module they probably want to run >stress tests, where XOR and PQ might be useful. ...and they would want the test selection to be specified on the kernel command line. At least that's how I used compiled in dmatest in the past. > >> there needs to be a way to prevent it from ever starting. > >My opinion I already shared, new node under debugfs. There is might be >a good reason to add a new module parameter as well. I'm not seeing why debugfs is helpful here. Just make it a module parameter that calls a routine to setup the bit mask. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
