Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
MIME-Version: 1.0
References: <20231206-rb-new-condvar-methods-v1-0-33a4cab7fdaa@google.com>
 <20231206-rb-new-condvar-methods-v1-2-33a4cab7fdaa@google.com>
 <ZXChjmoKPj3XnJgG@Boquns-Mac-mini.home> <20231206163945.GC36423@noisy.programming.kicks-ass.net>
 <CAH5fLgi56i70MaFaoLcWVw+nf-ZvOLpmA8bHNVX=VXTBkcSa4Q@mail.gmail.com> <20231206165314.GD36423@noisy.programming.kicks-ass.net>
In-Reply-To: <20231206165314.GD36423@noisy.programming.kicks-ass.net>
From:   Alice Ryhl <aliceryhl@google.com>
Date:   Wed, 6 Dec 2023 18:00:38 +0100
Message-ID: <CAH5fLgjeQFKvqqXUHi6xXKFRYD-jKHAEWPyKJPDnr9pmw0QKxg@mail.gmail.com>
Subject: Re: [PATCH 2/2] rust: sync: add `CondVar::wait_timeout`
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Boqun Feng <boqun.feng@gmail.com>, Miguel Ojeda <ojeda@kernel.org>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        Wedson Almeida Filho <wedsonaf@gmail.com>,
        Gary Guo <gary@garyguo.net>,
        =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>,
        Benno Lossin <benno.lossin@proton.me>,
        Andreas Hindborg <a.hindborg@samsung.com>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Waiman Long <longman@redhat.com>,
        rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
        Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Dec 6, 2023 at 5:53=E2=80=AFPM Peter Zijlstra <peterz@infradead.org=
> wrote:
>
> On Wed, Dec 06, 2023 at 05:42:29PM +0100, Alice Ryhl wrote:
> > On Wed, Dec 6, 2023 at 5:39=E2=80=AFPM Peter Zijlstra <peterz@infradead=
.org> wrote:
> > >
> > > On Wed, Dec 06, 2023 at 08:30:06AM -0800, Boqun Feng wrote:
> > > > On Wed, Dec 06, 2023 at 10:09:24AM +0000, Alice Ryhl wrote:
> > > > [...]
> > > > > +
> > > > > +/// The return type of `wait_timeout`.
> > > > > +pub enum CondVarTimeoutResult {
> > > > > +    /// The timeout was reached.
> > > > > +    Timeout,
> > > > > +    /// Somebody woke us up.
> > > > > +    Woken {
> > > > > +        /// Remaining sleep duration.
> > > > > +        jiffies: u64,
> > > >
> > > > I have a Jiffies definition in the my upcoming timer patchset:
> > > >
> > > > /// The time unit of Linux kernel. One jiffy equals (1/HZ) second.
> > > > pub type Jiffies =3D core::ffi::c_ulong;
> > > >
> > > > Maybe you can add that (in a separate patch) in kernel::time?
> > >
> > > Urgh, why are we using jiffies in 2023?
> >
> > I assumed that the correct thing here would be to accept the same unit
> > as what schedule_timeout takes. Should I be doing something else?
>
> Bah, so we have schedule_hrtimeout() that takes ktime/u64 nsec. But the
> 'problem' is that hrtimers are written with the expectation to fire,
> while the old timers are written with the expectation to not fire.
>
> Timeouts are typically best done with the latter, so in that regard
> using schedule_timeout() is right. But it is sad to inflict the
> brain-damage that is jiffies onto new code.
>
> Perhaps add schedule_timeout_*msec() wrappers around schedule_timeout*()
> and use a consistent sane time unit?
>
> Thomas?

Hmm, looking over my usage in Rust Binder again ... the unit I need
*is* msec, but when we are woken up, we sometimes just go to sleep
again, which means that we need to be able to pass the remaining
duration back to `wait_timeout` to continue sleeping. I'm guessing
that I would lose precision if I converted back/forth to msecs here?

Alice