From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 A02B520F999 for ; Wed, 15 Jan 2025 10:33:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736937183; cv=none; b=TTOM70XDiJRaKsosQspzXgNbXJTXtzAc+5Q6hGbMCAOuYBWJVqQfb3QVe9M6p0AGjI/llPiFRHpP6dztW+tE3tH/7Nba2ZuT2sj51KwN4mnQF7eiE5k0ThDC5gp4xumRmKWFt8M6HQRpEINgnafH1nOfhjj7m63Fnfhl1maxTy8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736937183; c=relaxed/simple; bh=qBFWW9SVz8O0DkUMwWNE1srvHUTlkCoYaQtDwC3qgHY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=m5GkwcDgezhW8GKmAw1PyV5OiQ+VVeC0SbfgE1iNevbb12lA2uBnVqm9VAxcew7U2XBbFiWpGsFPoCUWURh/pMehSqZA648mzIb3oQ4ZVi/KAMxbN/NZLTihdyTaiuPnDKzHBNLdpDyWkRa41YtglBNsV1mFjN7MR68Uthr2Jwg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=2vg02YEl; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=BIIs1rMd; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="2vg02YEl"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="BIIs1rMd" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1736937179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ra/67Fg9qjNrrrJeO4yb4+7Aft1Qin8Xc2e5rl953N8=; b=2vg02YEl5molPV1NT3v3cHAqSy/wPwrEuQvr0LaObT7IW40MdR0uU1HV0QlxOK2eOEPda5 tOfmBo9WATjgkDdexz3fCqf6tr4DK5R6ILnQKSiahWWohT0rwGaaSCDr+17FdOiWpaHOIL pZw1LFz4AGtB0msJh0OJIGNENmmJCbEGYFKwzjcyk65MBVE7M77JeNkBNrYJnTUfzp9vpy EQ/UKfdGh2WvdrnS5PwgOb/UL/oUTEqEqKHiu/DwHEGqwjEO9JMZB422Lt69XVmhxo/Zbq u6I3tdphSjSe64ViObowloSFbw9MTMd9f+PkpDQrFB1mgYpG9XwrB0ZtB3ryRA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1736937179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ra/67Fg9qjNrrrJeO4yb4+7Aft1Qin8Xc2e5rl953N8=; b=BIIs1rMdfGJnsfh+Ka9B8AbAEIcHC0FM+INpumetctPVbNxfbWvPPJnj3roBYUtI/r84L6 3yxHqnrCSADTF2CQ== To: imran.f.khan@oracle.com Cc: john.stultz@linaro.org, sboyd@kernel.org, linux-kernel@vger.kernel.org Subject: Re: Query about timer wheel API In-Reply-To: <0a83e9e1-3e85-4c33-bec8-6b60e6216bd8@oracle.com> References: <0a83e9e1-3e85-4c33-bec8-6b60e6216bd8@oracle.com> Date: Wed, 15 Jan 2025 11:32:59 +0100 Message-ID: <874j20cqp0.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, Dec 23 2024 at 11:14, imran f. khan wrote: > Could you kindly help me, regarding a query about timer wheel APIs. > Right now we use add_timer or add_timer_on, to add a timer to any > or to a specific CPU respectively. > Would it be useful to have an interface like try_add_timer_on, that > would return an error or would use add_timer, if the specified CPU is > offline. > > Recently we have come across some bugs in the RDS code, where a delayed > work was being queued on an offlined CPU and as a result of that the > underlying timer was not firing, which in turn meant that the work was > never able to make it to the intended worker_pool. Urgh. Clearly add_timer_on() lacks a check and a warning for that. > I understand that this is something that needs fixing at caller side and > we are taking that approach. > > But I also wanted to understand if there is some scope of change on timer > side, for such situations. I saw your reply in [1] and agree with your point. > But that conversation is more than a decade old, so I thought of asking this > question, assuming that there may be some other use cases that can utilize > this new interface. > > One can also ask to change queue_delayed_work_on or have an equivalent, > that would check if CPU is online before doing add_timer_on but I am not sure > if workqueue is the only subsystem that can run into this situation. I have no idea. That said, I'm not opposed to have a function like timer_try_add_on_cpu(), which validates that the CPU is online and returns true if the timer is queued or false if the target CPU is offline. Then the call site can decided what to do with that situation. That's way better than queueing it on some randomly picked online CPU silently. Thanks, tglx