Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Randhawa, Jagmeet" <jagmeet.randhawa@intel.com>
To: "Cavitt, Jonathan" <jonathan.cavitt@intel.com>
Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>
Subject: Re: [PATCH] [i-g-t] tests/intel/xe_vm:Reduce n_execs for bind-array-enobufs
Date: Wed, 23 Oct 2024 13:29:06 -0700	[thread overview]
Message-ID: <cacecbfd-7037-44bc-97f1-425e2626b9a1@intel.com> (raw)
In-Reply-To: <CH0PR11MB54441E7BEAC825A733D6B600E54D2@CH0PR11MB5444.namprd11.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 3095 bytes --]


On 10/23/2024 7:12 AM, Cavitt, Jonathan wrote:
> -----Original Message-----
> From: Randhawa, Jagmeet<jagmeet.randhawa@intel.com> 
> Sent: Tuesday, October 22, 2024 1:12 PM
> Cc:igt-dev@lists.freedesktop.org; Cavitt, Jonathan<jonathan.cavitt@intel.com>; Zuo, Alex<alex.zuo@intel.com>; Konieczny, Kamil<kamil.konieczny@intel.com>; Randhawa, Jagmeet<jagmeet.randhawa@intel.com>
> Subject: [PATCH] [i-g-t] tests/intel/xe_vm:Reduce n_execs for bind-array-enobufs
>> The bind-array-enobufs test in xe_vm.c is intended to trigger
>> an -ENOBUFS error by submitting an oversized bind array.
>> After encountering and handling the error, the test reduces
>> n_execs by half and retries the operation. On some environments
>> with stricter resource limits (e.g. simulator),
> Is it "just" simulator this is an issue on?  Because if so, we could probably
> use igt_run_in_simulation() to narrow the scope:
>
> """
> 		xe_cork_fini(&cork);
> -		n_execs = n_execs / 2;
> +		n_execs /= igt_run_in_simulation() ? 4 : 2;
> }
> """
>
> If not, then
> Reviewed-by: Jonathan Cavitt<jonathan.cavitt@intel.com>
> -Jonathan Cavitt

Thank you for your comment and review Jonathan. Oddly when I tested the 
following line

  "n_execs /= igt_run_in_simulation() ? 4 : 2;" The test fails as it was 
before the original patch was sent

so I suspect igt_run_in_simulation() is returning false and we are 
taking the "2" integer in this case.

I believe it is just simulator we are facing this issue on, however I 
think leaving the code as

"n_execs = n_execs / 4;" doesn't do any harm if we run it on any other platform such as hardware
, as it does not affect the basis of the test which is to trigger enobufs error, handle it, and then
run with less n_execs to pass on the next iterations. This patch will just accelerate the test on hardware.
If this works with you, may I ask if I still have your reviewed-by? I can change it and investigate
if you feel strongly about it. Thanks again.

Jagmeet

>
>> halving n_execs isn't sufficient to prevent the ENOBUFS error on the retry.
>> Reducing n_execs further to n_execs / 4 allows the test to pass
>> successfully. This patch modifies the test to reduce n_execs
>> to n_execs / 4 after an ENOBUFS error is handled. This ensures
>> compatibility with environments that have tighter resource
>> constraints while maintaining the test's integrity.
>>
>> Cc: Jonathan Cavitt<jonathan.cavitt@intel.com>
>> Signed-off-by: Jagmeet Randhawa<jagmeet.randhawa@intel.com>
>> ---
>>   tests/intel/xe_vm.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/intel/xe_vm.c b/tests/intel/xe_vm.c
>> index 7a8740b69..e78ddd0e5 100644
>> --- a/tests/intel/xe_vm.c
>> +++ b/tests/intel/xe_vm.c
>> @@ -957,7 +957,7 @@ test_bind_array(int fd, struct drm_xe_engine_class_instance *eci, int n_execs,
>>   		xe_cork_end(&cork);
>>   		xe_cork_wait_done(&cork);
>>   		xe_cork_fini(&cork);
>> -		n_execs = n_execs / 2;
>> +		n_execs = n_execs / 4;
>>   	}
>>   
>>   	xe_vm_bind_array(fd, vm, bind_exec_queue, bind_ops, n_execs, sync, 1);
>> -- 
>> 2.34.1
>>
>>

[-- Attachment #2: Type: text/html, Size: 4948 bytes --]

  reply	other threads:[~2024-10-23 20:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-22 20:11 [PATCH] [i-g-t] tests/intel/xe_vm:Reduce n_execs for bind-array-enobufs Jagmeet Randhawa
2024-10-22 21:05 ` ✗ Fi.CI.BAT: failure for " Patchwork
2024-10-28 16:56   ` Kamil Konieczny
2024-10-22 21:46 ` ✓ CI.xeBAT: success " Patchwork
2024-10-23  4:37 ` ✗ CI.xeFULL: failure " Patchwork
2024-10-28 16:55   ` Kamil Konieczny
2024-11-05 20:33     ` Randhawa, Jagmeet
2024-10-23 14:12 ` [PATCH] [i-g-t] " Cavitt, Jonathan
2024-10-23 20:29   ` Randhawa, Jagmeet [this message]
2024-10-23 20:35     ` Cavitt, Jonathan
2024-10-28 16:53 ` Kamil Konieczny
2024-11-05 20:31   ` Randhawa, Jagmeet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cacecbfd-7037-44bc-97f1-425e2626b9a1@intel.com \
    --to=jagmeet.randhawa@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jonathan.cavitt@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox