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.
Signed-off-by: Jon Mason <[email protected]>
---
drivers/dma/dmatest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index d8ce4ec..7de610d 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -904,11 +904,11 @@ static int dmatest_add_channel(struct dmatest_info *info,
cnt = dmatest_add_threads(info, dtc, DMA_MEMCPY);
thread_count += cnt > 0 ? cnt : 0;
}
- if (dma_has_cap(DMA_XOR, dma_dev->cap_mask)) {
+ if (dma_has_cap(DMA_XOR, dma_dev->cap_mask) && xor_sources) {
cnt = dmatest_add_threads(info, dtc, DMA_XOR);
thread_count += cnt > 0 ? cnt : 0;
}
- if (dma_has_cap(DMA_PQ, dma_dev->cap_mask)) {
+ if (dma_has_cap(DMA_PQ, dma_dev->cap_mask) && pq_sources) {
cnt = dmatest_add_threads(info, dtc, DMA_PQ);
thread_count += cnt > 0 ? cnt : 0;
}
--
1.7.9.5
On Fri, May 17, 2013 at 8:54 PM, Jon Mason <[email protected]> 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.
--
With Best Regards,
Andy Shevchenko
On Fri, May 31, 2013 at 11:22:10AM +0300, Andy Shevchenko wrote:
> On Fri, May 17, 2013 at 8:54 PM, Jon Mason <[email protected]> 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. Since the testing is started immediately upon module
insertion, there needs to be a way to prevent it from ever starting.
Thanks,
Jon
>
> --
> With Best Regards,
> Andy Shevchenko
On Tue, Jun 4, 2013 at 2:29 AM, Jon Mason <[email protected]> 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 <[email protected]> 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.
Moreover, your patch doesn't cover the case when user doesn't want to
run MEMCPY thread.
> 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.
> 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.
--
With Best Regards,
Andy Shevchenko
On 6/4/13 12:25 AM, "Andy Shevchenko" <[email protected]> wrote:
>On Tue, Jun 4, 2013 at 2:29 AM, Jon Mason <[email protected]> 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 <[email protected]> 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
On Tue, Jun 4, 2013 at 8:11 PM, Dan Williams <[email protected]> wrote:
> On 6/4/13 12:25 AM, "Andy Shevchenko" <[email protected]> wrote:
>>On Tue, Jun 4, 2013 at 2:29 AM, Jon Mason <[email protected]> wrote:
>>> On Fri, May 31, 2013 at 11:22:10AM +0300, Andy Shevchenko wrote:
[]
>>> 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.
Actually you're right. Better to have it in that case too.
>>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.
I'm not objecting against module parameter, though I would like to see
debugfs node for that as well.
--
With Best Regards,
Andy Shevchenko