Messages in this thread | | | From | Dan Williams <> | Subject | Re: [PATCH] dmatest: add ability to disable pq and xor | Date | Tue, 4 Jun 2013 17:11:51 +0000 |
| |
On 6/4/13 12:25 AM, "Andy Shevchenko" <andy.shevchenko@gmail.com> wrote:
>On Tue, Jun 4, 2013 at 2:29 AM, Jon Mason <jon.mason@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.mason@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
| |