From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fanzine2.igalia.com (fanzine.igalia.com [178.60.130.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1317624 for ; Sun, 22 Dec 2024 04:33:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=178.60.130.6 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734842004; cv=none; b=pDCCEomQ//yBu4Yvhk9/0RVIZjCBzeAtTsXaRtmjm3mm/xOcp5VAORkNsxII58RRWjhKa4jtHGo6rLE67Evomu6hl3zZuoSnZKkdhCF1xOtzPdmP7w82Gk5K/7mo7hRK1ZZUJu6ZBTuQ/5g9nbRQfTfcvedCb3Y0ij2CEzQPjJA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734842004; c=relaxed/simple; bh=DjMSLA/zp1JZyxgtgTyLHuLXfPeXD8p6KV3+MFrns4k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ABS0KgrVyCM//VwbU+SBxNwfnEjOi8ziNtTUR4Wp1xgV9lK8Z+xe11nvOVz/Jn7/i3xUUzpy/grd0c5rlx9aSAKn92Sl6HSG1ZRbPGvwZDLqF5+Ak8kLu+1QIlAh7OZsdxRpOomXUo+iSmfPl7fesL9s2cJnoZJkulWqnpbhBoA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com; spf=pass smtp.mailfrom=igalia.com; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b=V+y1KXWX; arc=none smtp.client-ip=178.60.130.6 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=igalia.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=igalia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=igalia.com header.i=@igalia.com header.b="V+y1KXWX" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=vfHC0RR57ABnqdohnX79nRNZaXweww83o6iQ4p2nDcI=; b=V+y1KXWX7LY5wTzZmDuCsDWc9v 33BflWPtz28bIVcrALKKqgADlJ09+YC4Gt5dkQ/ajZ5i2v+wQV7JBmqRX3EerKUHQXyZC798jY15j pdUryksOAROARybjoQ0j5yADBlPLRHdUdL5nF2YBmOqNsNAfIePgMmez6AqLXYhUMJf57j4S1BQr9 ncJsME45MszT3ujixuJi1KBvBReYPMGGR1AesCm06wd50+PnY9PqzUxqrOgouNrOi1oLhMQKg62J0 6WPx8EUHf+0t1bNlRSmQ0HMfM4zqYIf6pcfIDpsjJJ4byqKJbjPRHmvIdxIOtGnw1p08l+p/iSurp O5jouLnA==; Received: from [58.29.143.236] (helo=[192.168.1.6]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1tPDeA-006NaC-B9; Sun, 22 Dec 2024 05:32:54 +0100 Message-ID: Date: Sun, 22 Dec 2024 13:32:45 +0900 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: [PATCH v6 2/6] sched_ext: Implement scx_bpf_now_ns() To: Andrea Righi Cc: tj@kernel.org, void@manifault.com, mingo@redhat.com, peterz@infradead.org, kernel-dev@igalia.com, linux-kernel@vger.kernel.org References: <20241220062025.27724-1-changwoo@igalia.com> <20241220062025.27724-3-changwoo@igalia.com> From: Changwoo Min Content-Language: en-US, ko-KR, en-US-large, ko In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andrea, On 24. 12. 21. 06:30, Andrea Righi wrote: > Hi Changwoo, > > On Fri, Dec 20, 2024 at 03:20:21PM +0900, Changwoo Min wrote: > ... >> + /* >> + * If the rq clock is valid, use the cached rq clock. >> + * Otherwise, return a fresh rq glock. > > s/glock/clock/ Opps. My bad. >> + if (!(READ_ONCE(rq->scx.flags) & SCX_RQ_CLK_VALID)) { >> + clock = sched_clock_cpu(cpu_of(rq)); >> + >> + /* >> + * The rq clock is updated outside of the rq lock. >> + * In this case, keep the updated rq clock invalid so the next >> + * kfunc call outside the rq lock gets a fresh rq clock. >> + */ >> + scx_rq_clock_update(rq, clock, false); >> + } > > I was wondering if we could use a special value for clock (like ~0ULL or > similar) to mark the clock as invalid. > > This way, we could get rid of the extra READ_ONCE(rq->scx.flags) logic for > checking the clock validity. And if the actual clock happens to match the > special value, we'd simply re-read the TSC, which shouldn't be a big issue > in theory. Thank you for the suggestion. In theory, the clock can overflow, so it would be hard to reserve a specific value. I think it would be better to keep the code as it is. Regards, Changwoo Min