From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3ED132D6409 for ; Thu, 5 Feb 2026 09:53:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770285188; cv=none; b=T+fG8ilUjLfATOkaDeYnLiFad22qJ3j7UlH5LrO4AGQBoLA5zK+9wwPKogB9i6Ju0G19lVJrB71PIq1TLHNp+l1E8OrtDfnyvbwF1KzvhqL2WeBT82v0x7/LnmnLq648j21aDz70I+EJGslOy3RSP3dmUWtkMRdHjqfPH60Uqoc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770285188; c=relaxed/simple; bh=ilToj3kkQDYaIitm/2pKiOT9qPifahktv/5/fulFBLo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=mZTycmh+cYo2ntXpaypgE7rT9hPHuMq88zfkm8sCdpIrlbQ+OQXd1VB2IbOW76z/cuvHgO+aolPtGNpB7Rk4V2cuV8AidlRODLtUnXemZ82oSugW0d4pL5jEr5RbzZpJoMOnz5v257kwjU2E2UZ8UPOSYEErdN7cVdxCXavm1gg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ursulin.net; spf=pass smtp.mailfrom=ursulin.net; dkim=pass (2048-bit key) header.d=ursulin.net header.i=@ursulin.net header.b=Z0n900DU; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ursulin.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ursulin.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ursulin.net header.i=@ursulin.net header.b="Z0n900DU" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-480706554beso7462275e9.1 for ; Thu, 05 Feb 2026 01:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ursulin.net; s=google; t=1770285186; x=1770889986; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Jt5qFgvsp4y6rljnasFjorD9RMuETz1hh2SdwFEi/FA=; b=Z0n900DUkFpyzTMJQpOVbSBsvDvzujuaSWqd2xl0tGkAl+6vhkOgslCifR9Rp1G5sl 55ngWDV+knWaBbbdqocFdAC0DNWTxZE19V+Mp2uoozeUNhpFfDcXANBL3uv0hAbQt2N3 zKiVBcUJNusi2L6JOkzcjWs85WFW3aiBBT1X9HOPXmjo8VKterRhdvqUWmmAkraLTMnW cQcorefH1Kfxo7TTFQatsRAHbll76nD28fNeGc7pyZjXpxVuPz2COGPpm6WgrylxzkHn WFjmfB0Qm7Th0IAGnHas4PVJmAh5wItRNgSTibErFppDLvRDPrShEf9YDMS4dyknvvCk 3sKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770285186; x=1770889986; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Jt5qFgvsp4y6rljnasFjorD9RMuETz1hh2SdwFEi/FA=; b=I9UrFAaSaTKMLTJ3HIAmCBnmvSxWwU0pT3yPeSD64NAIp1O6uw6E8p5oOvHesTxpt3 DAOCKkJDwgj0N1Dlt32LVG9Z8kH30EPRfT9cvHab+j3GhvVRqE7my8MSoRuzjeTXX0Xx lfB8K1WoOxRo1YP6C0kKoXZpt8LOx8svV60/R5OOqW1Zn5HgVeE7unZWM6hYqjJMD2PY um6d9XaiS7NWPbO0OW52dIm24N/U9IP8pVp+swd/BaqyhAZwMrI0hpuNLbCgryrFegQ/ lI6GkiJNcbcRXwluqS9of9r3FJxBzqksUFGFmtmuyVEAUBNxdZoIjXL36YRWCTW5pC2k gNtA== X-Forwarded-Encrypted: i=1; AJvYcCUoyQsAVj6t4U0fX69586EKbMqMicgpE95gNh/4iLPveSkzVWg36pXqAP0usyxK38IXZr4gpKtRZi+QqTA=@vger.kernel.org X-Gm-Message-State: AOJu0YyvYcnvSQMfLbH9jL5v8BqOyOQHeaY8JkIREF3+EdDE+M5Hj3xP tzazmJRZONUhmOCUQstqOAaaPs1+2EDnRS4IED21nhIZmxYmobMqdL7lZ5endw9t7pQ= X-Gm-Gg: AZuq6aKwC/dkxd668eLt+UG0TFfek8Wgw+rXJPwCKpJCEyc8YKkZlPhhH2VjcrWA2ka CKSW4P3jtMSdWXNVI5mi/EwbwVYx4hEWiWvpufOH8bh4DVhNVzet5onzOe2jYyGgVnm2WQzfjzw SWL0kyS9TsS+RbZszWZ7rwkPj1GWdY7cowojX9KWFh6qVRoXTsUX2Zy7u2/8jrKNwH4NkJBFnZB 3lv1iso0AMngo/KbIFfnf+zoS+rG3MPx2R0nbjqPlInSVSeFhsEJELA267rMJ9Zh1aENXHYWZ/3 GglkATwnF8tyKWNPmvGVluc+7xmzrt5pk41WgYe9rGg+uKmXdm8B3jFaXIBC9l/tJA0Dc1l41Yt EQtkrfD3QEUG+6GcwrDmhkw+aixv3aITYq9uyfoVkK3WJ4llMWamfhyX/XdI0WX849gVu6xCsMC W8VbPu3Tc/MFZ6ie6V/dKuEgAl9x2Bm2ox X-Received: by 2002:a05:600c:3e11:b0:482:f564:d613 with SMTP id 5b1f17b1804b1-4830e93ee70mr82093775e9.15.1770285186175; Thu, 05 Feb 2026 01:53:06 -0800 (PST) Received: from [192.168.0.101] ([90.240.106.137]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-436234781fbsm3315701f8f.15.2026.02.05.01.53.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Feb 2026 01:53:05 -0800 (PST) Message-ID: <07c8c588-c2d6-463d-aabc-d472b8f38be8@ursulin.net> Date: Thu, 5 Feb 2026 09:53:05 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] drm/sched: Add new KUnit test suite for concurrent job submission To: Marco Pagani Cc: airlied@gmail.com, ckoenig.leichtzumerken@gmail.com, dakr@kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, maarten.lankhorst@linux.intel.com, marpagan@redhat.com, matthew.brost@intel.com, mripard@kernel.org, phasta@kernel.org, simona@ffwll.ch, tzimmermann@suse.de References: <79cf2013-da6b-4653-aaa8-3e29a7d1ee3a@ursulin.net> <90cdb121-7ff2-43a5-9327-2898b5e65609@linux.dev> <36b2f7b1-f38e-41b6-b7e5-107a80c028d0@ursulin.net> Content-Language: en-GB From: Tvrtko Ursulin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/02/2026 16:33, Marco Pagani wrote: 8>< >>>>> + { >>>>> + .description = "Concurrently submit multiple jobs in a single entity", >>>>> + .job_base_us = 1000, >>>>> + .num_jobs = 10, >>>>> + .num_subs = 64, >>>>> + }, >>>>> +}; >>>>> + >>>>> +static void >>>>> +drm_sched_concurrent_desc(const struct drm_sched_concurrent_params *params, char *desc) >>>>> +{ >>>>> + strscpy(desc, params->description, KUNIT_PARAM_DESC_SIZE); >>>>> +} >>>>> + >>>>> +KUNIT_ARRAY_PARAM(drm_sched_concurrent, drm_sched_concurrent_cases, drm_sched_concurrent_desc); >>>>> + >>>>> +struct submitter_data { >>>>> + struct work_struct work; >>>>> + struct sched_concurrent_test_context *ctx; >>>>> + struct drm_mock_sched_entity *entity; >>>>> + struct drm_mock_sched_job **jobs; >>>>> + struct kunit *test; >>>>> + unsigned int id; >>>>> + bool timedout; >>>>> +}; >>>>> + >>>>> +static void drm_sched_submitter_worker(struct work_struct *work) >>>>> +{ >>>>> + const struct drm_sched_concurrent_params *params; >>>>> + struct sched_concurrent_test_context *ctx; >>>>> + struct submitter_data *sub_data; >>>>> + unsigned int i, duration_us; >>>>> + unsigned long timeout_jiffies; >>>>> + bool done; >>>>> + >>>>> + sub_data = container_of(work, struct submitter_data, work); >>>>> + ctx = sub_data->ctx; >>>>> + params = sub_data->test->param_value; >>>>> + >>>>> + wait_for_completion(&ctx->wait_go); >>>>> + >>>>> + for (i = 0; i < params->num_jobs; i++) { >>>>> + duration_us = params->job_base_us + (sub_data->id * 10); >>>> >>>> Why is job duration dependent by the submitter id? >>> >>> Just a simple way to have a deterministic distribution of durations. >>> I can change it if it doesn't fit. >>> >>>> Would it be feasiable to not use auto-completing jobs and instead >>>> advance the timeline manually? Given how the premise of the test seems >>>> to be about concurrent submission it sounds plausible that what happens >>>> after submission maybe isn't very relevant. >>> >>> Good idea! I'll run some experiments and see if it works. >> >> Cool, I will await your findings in v2. :) > > > After fiddling a bit with the code, I came to the conclusion that > changing the design to use manual timeline advancement is doable, but > not beneficial, since it would require serializing job submission into > "batches" using a two-step process, i.e., (i) workers submit jobs, and > (ii) the main thread waits for all submissions, advances the timeline, > and then releases the workers for the next iteration. What do you mean by next iteration? In the patch you have each worker submit all jobs in one go. > This approach would partially defeat the purpose of a concurrency test > as it would not allow job submission (KUnit process context) to overlap > with job completion (hrtimer callback interrupt context) that models > asynchronous hardware in the mock scheduler, limiting contention on the > DRM scheduler internal locking. Moreover, while manual advancement might > appear to make the test deterministic, it does not since the order in > which the workers are scheduled will still be non-deterministic. Ah, so it depends what is the test actually wanting to test. In my view exercising parallel submit is one thing, while interleaving submission with completion is something else. In the test as written I think there is very little of the latter. Each worker submits all their jobs in one tight loop. Jobs you set to be 1ms so first job completion is 1ms away from when workers are released. A lot of the jobs can be submitted in 1ms and it would be interesting to see exactly how much, from how many workers. If desire is to interleave completion and submission I think that should be made more explicit (less depending on how fast is the underlying machine). For example adding delays into the submit loop to actually guarantee that. But I would also recommend parallel submit and parallel submit vs completions are tested in separate test cases. It should be easy to do with some flags and almost no new code. I was suggesting flags for some other thing in the initial review as well. Right, for auto-complete. So flag could be something like: +static const struct drm_sched_concurrent_params drm_sched_concurrent_cases[] = { + { + .description = "Concurrently submit a single job in a single entity", + .job_base_us = 1000, + .num_jobs = 1, + .num_subs = 32, .flags = INTERLEAVE_SUBMIT_AND_COMPLETE, + }, In the submit loop: + for (i = 0; i < params->num_jobs; i++) { + duration_us = params->job_base_us + (sub_data->id * 10); if (flags & INTERLEAVE_SUBMIT_AND_COMPLETE) { drm_mock_sched_job_set_duration_us(sub_data->jobs[i], duration_us); // Add a delay based on time elapse and job duration to guarantee job completions start arriving } + drm_mock_sched_job_submit(sub_data->jobs[i]); + } And of course handle the job waiting stage appropriately depending on auto-complete or not. Anyway, testing as little as possible at a time is a best practice I recommend, but if you insist, there is also nothing fundamentally wrong with the test as you have it so I won't block it. Regards, Tvrtko