From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (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 D82C933290D for ; Mon, 29 Dec 2025 18:55:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767034532; cv=none; b=IPVnazG92odAT0dmvGwRkhuzF8KJmuC+saLTCU2DJ05Z1lRVIamn4X28WdOT9VWRZ4UMd8ZudLk7T7LSPimg7RrtPXMxnz32xm07WRphsKNMytx9CroaV+dV8usQ5lcSwnMzMf5MugvAPxJxmRmmbd2FCc8J9qvpiKux8lZjloM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767034532; c=relaxed/simple; bh=cjoFnLYs0hXLzQWrJlFdFTYh+Jvet5KgFjIFyY4E0uw=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=ikQqZRlfjpqUCxP1+fqUs1i4Ps8DBkimxow+CAEvuyEQ+u/jFX4Hv6tSCqRGhkvIOD29pV/aGsDWhK2Bj9/GLC5AOOLcpKCF1KF72zDDVr1mpnuDnmW//wzJ4y+mUBuhDrkh4Lr35rVgo1v5Ew/g53151h+VZ4X89UYC+hbvhDc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com; spf=pass smtp.mailfrom=etsalapatis.com; dkim=pass (2048-bit key) header.d=etsalapatis-com.20230601.gappssmtp.com header.i=@etsalapatis-com.20230601.gappssmtp.com header.b=yh5d2BXb; arc=none smtp.client-ip=209.85.160.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=etsalapatis.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=etsalapatis-com.20230601.gappssmtp.com header.i=@etsalapatis-com.20230601.gappssmtp.com header.b="yh5d2BXb" Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4f1b212ba25so81891481cf.2 for ; Mon, 29 Dec 2025 10:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=etsalapatis-com.20230601.gappssmtp.com; s=20230601; t=1767034528; x=1767639328; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6bFyx9qM3TGN99UnGzsweyG3odVGHIhrJQXh5a9SKgI=; b=yh5d2BXbqL+3buKj2B3vhA6lKWmE39x/NU990rgb0VuOrYj7iwUmbJW+Q7F6ahkTPI +JPlzdIZPsn2F1mtSbPApI3gUK8IZW7knEKm3bo+xcb0EK/rTTJc+mEUROPqo++djD8b 1Q+5kxX7D5iKCGDj33Z50KWmB2OKhCUUIEYYFDcp4wXhzB0OisVYSMpqVbJFPIJXp8hj zIm/IVngcmEogqbyWJ7LajAlHN4Q4BRXBpdadWSm0HB20ULIBAgwGyfNO+noyDrxVsa9 xZLF2ir1GfnEUMeqN0dQnk/zP8FwEj/QFugG2D9S5ng7ybWGnZkHwriaZJj0kK3u8PlQ QpSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767034528; x=1767639328; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6bFyx9qM3TGN99UnGzsweyG3odVGHIhrJQXh5a9SKgI=; b=dkNUQenXPLUiu+Ab6cPTE0Nn8EIS6jbAWHgvVmNAl8WWZnVLtVZSkOILBRLOoOQ634 ys4qHbshawTnxwxWNIFEiiIi/PY+3hwtEzmUdTnMcg/9uGdmr3Ikir/T+Em6f2VTgTmx fpKta9ya1sx1FBCIpWLa6ZMC5HYFtow1cn9qYf6rkVv2Fmw81SZ9e6DsdzfjnhaIQWTp eUQlFq22COkpJXsjm9Rc3PudKJPyyh9BTKU6bMpXAucZVmwFdwFv1BBzRVt1+VJKz0lC wRm9Ti7TIBz1xawSQmY4cybA0Dzl2HKZL7ZQC6f3moR87WM0Wok0ZrYtMU46w/8/WO4R +jrw== X-Forwarded-Encrypted: i=1; AJvYcCW5lCdLtfRXs66fw8Y5u2Ywf3BKsy6+Mt3THAKmuc3JViIyWEreq4xtvXkrp3SjVdiNxWlAAvtfbU8RaKA=@vger.kernel.org X-Gm-Message-State: AOJu0YxwNlIdI/kssgOPu7TPz8JYsXYtd8dzSXYjJv+NvxZtvYdN5p3b PA6IpQkWWo2vkBCDtzCTof/vK/1NijSH8EAbNxM1Y2c7ZYRK6Lgz3l76ucPI10PYkso= X-Gm-Gg: AY/fxX5dSIST7S8ubX7lpIoZaYmW3U4HHq8WSFO795py81DbN2XzOzIgCbghwCey3g9 RISCczMFo9gRJk6LDCqdttk8CpazsLT84BMzJ6AOc2j6GjY+ZEmDU8yGMHDf5pLqZLEBZhXX9pm 6iMnuYEr68Km6vqGImRoXIJgODVQ2+O+tI+Scw4CoOfG0wtfu1CFCnDCKLrOZg2DDxMcGEUY/Fy Bmon48SIvZJsdvIF3FIvPbT5x4HWu+2dqlPPWaHWaYbuBUu7oO027XUDoPgy2D+EmUmCed0UgsY GNwUlksgjDxM2miy9Wr9ET1hf+9T+fmiu4iSipywYNU3RjkLJxFMPqiaELy3LcNsxIJINskMFJn O+fOaqBUL6ZW03tgDkZpD9o8LSXF42HZdcCpcsixxRm0ChBFgmu1AiNTr2MoXmb7Cpi2QvJskMm RFeU0aPjU2AfQ= X-Google-Smtp-Source: AGHT+IFrwHFt1aHfOKlLIBCZlzI3NpSi0gqjyGcHD73ZWAtouJw5+qx0glKFUfHSH1ie9FuO8K7UZA== X-Received: by 2002:a05:622a:5c91:b0:4ed:dcf0:6c42 with SMTP id d75a77b69052e-4f4abd8cb47mr520776471cf.40.1767034528560; Mon, 29 Dec 2025 10:55:28 -0800 (PST) Received: from localhost ([140.174.219.137]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4f4b6760a43sm207769901cf.22.2025.12.29.10.55.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Dec 2025 10:55:28 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 29 Dec 2025 13:55:26 -0500 Message-Id: Cc: "David Vernet" , "Changwoo Min" , "Daniel Hodges" , , Subject: Re: [PATCH 1/2] sched_ext: Fix ops.dequeue() semantics From: "Emil Tsalapatis" To: "Andrea Righi" , "Tejun Heo" X-Mailer: aerc 0.20.1 References: <20251219224450.2537941-1-arighi@nvidia.com> <20251219224450.2537941-2-arighi@nvidia.com> In-Reply-To: On Mon Dec 29, 2025 at 12:07 PM EST, Andrea Righi wrote: > Hi Tejun, > > On Sun, Dec 28, 2025 at 01:38:01PM -1000, Tejun Heo wrote: >> Hello again, again. >>=20 >> On Sun, Dec 28, 2025 at 01:28:04PM -1000, Tejun Heo wrote: >> ... >> > So, please ignore that part. That's non-sense. I still wonder whether = we can >> > create some interlocking between scx_bpf_dsq_insert() and ops.dequeue(= ) >> > without making hot path slower. I'll think more about it. >>=20 >> And we can't create an interlocking between scx_bpf_dsq_insert() and >> ops.dequeue() without adding extra atomic operations in hot paths. The o= nly >> thing shared is task rq lock and dispatch path can't do that synchronous= ly. >> So, yeah, it looks like the best we can do is always letting the BPF sch= ed >> know and let it figure out locking and whether the task needs to be >> dequeued from BPF side. > > How about setting a flag in deq_flags to distinguish between a "dispatch" > dequeue vs a real dequeue (due to property changes or other reasons)? > > We should be able to pass this information in a reliable way without any > additional synchronization in the hot paths. This would let schedulers th= at > use arena data structures check the flag instead of doing their own > internal lookups. > > And it would also allow us to provide both semantics: > 1) Catch real dequeues that need special BPF-side actions (check the flag= ) > 2) Track all ops.enqueue()/ops.dequeue() pairs for accounting purposes > (ignore the flag) > IMO the extra flag suffices for arena-based queueing, the arena data structures already have to track the state of the task already: Even without the flag it should be possible to infer the task is in in from inside the BPF code. For example, calling .dequeue() while=20 the task is in an arena queue means the task got dequeued _after_ being dispatched, while calling .dequeue() on a queued task means we are removing it because of a true dequeue event (e.g. sched_setaffinity() was called). The only edge case in the logic is if a true dequeue event=20 happens between .dispatch() and .dequeue(), but a new flag would take=20 care of that. > Thanks, > -Andrea