From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp134-25.sina.com.cn (smtp134-25.sina.com.cn [180.149.134.25]) (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 76A9C1369AE for ; Wed, 25 Dec 2024 11:07:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=180.149.134.25 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735124854; cv=none; b=unaN98XKAWubM5tfDtoGILx4gJsEd7AgWPrbo4lOhjHReYiz5mnMfoHByG76m09S5pljI6lF+B1EkoR0ikrHqgdVvrogC7FwIUbYKJhvdaln3G8gwdgY44S9cACvaVCa9eSSlKGvqxswxOV8/BWuS+/om/YYCMtGmC5eWyJdzRI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735124854; c=relaxed/simple; bh=8JuGq6wOZZTD8LRdPqSfBOv8vkj4woDGfUWCUMDERP0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ixq1uyCM6nnuj+VR++cfg9iKMj1K73+YNLgG7Oqwhb6+STi0tcBAJD6zrYhiz9yMYrLjfUNbZAQ2/Q43lzYfEdN6n/Ac+tZGU+bFZOIoYEQo4pieOxzqbb0jMyGcYErvbrzPVGO+L44zauffSrbmkXt/bOJw7X8PVFSU7Db2LQ0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; arc=none smtp.client-ip=180.149.134.25 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.118.66.107]) by sina.com (10.185.250.21) with ESMTP id 676BE61A00001876; Wed, 25 Dec 2024 19:01:50 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 1122863408195 X-SMAIL-UIID: 40C280773C224DDCAAD2755FEC4C67EC-20241225-190150-1 From: Hillf Danton To: imran.f.khan@oracle.com Cc: Thomas Gleixner , Tejun Heo , john.stultz@linaro.org, sboyd@kernel.org, linux-kernel@vger.kernel.org Subject: Re: Query about timer wheel API Date: Wed, 25 Dec 2024 19:01:45 +0800 Message-ID: <20241225110146.482-1-hdanton@sina.com> In-Reply-To: <910a73af-a221-4e5b-ad5b-a2a1bdb8c8c3@oracle.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 24 Dec 2024 23:41:48 +1100 imran.f.khan@oracle.com > > the query was not about why its (not) working with my module. The test module, in its > current form, is just to show that a timer-wheel timer could be inserted in timer list > of an offlined CPU. Your module helps understand your query. > > What you have suggested, we are already doing it in RDS code (mentioned in my earlier messages). > Also just using cpu_online may not be enough, unless we do it under get/put_online_cpus. > Same pattern is in smp_call_function_single() where ckecking cpu after get_cpu(). But different one in smp_call_on_cpu(). > If you see, my query was more towards, what should "add_timer_on" do for such cases or > can we have another function like try_add_timer_on that tries to put the timer on specific > CPU, but puts it else where if that CPU is offline. Is it worth having such an interface > or should we stick to the current approach of fixing this on the caller side. The number of reports that timer is queued on offline cpu in 2024 alone raises the (known) question -- what sense could be made by adding check of cpu in the pathes like queuing work and arming timer?