Received-SPF: pass (google.com: domain of linux-kernel+bounces-31622-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240118181459.1663313-1-pranavpp@google.com> <CANDhNCqyugdsais9bzaL8RxTxyBgme4W2ZdfayaS8HbqBHJraw@mail.gmail.com>
 <87y1cldsgq.ffs@tglx>
In-Reply-To: <87y1cldsgq.ffs@tglx>
From: Pranav Prasad <pranavpp@google.com>
Date: Fri, 19 Jan 2024 15:09:22 -0800
Message-ID: <CACkwYU2psvrCKNKQBRngYtj3xRgnBo0wa1L644tq2nP+8tb-5w@mail.gmail.com>
Subject: Re: [PATCH] alarmtimer: Expose information about next alarm to
 userspace via sysfs
To: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <jstultz@google.com>, sboyd@kernel.org, linux-kernel@vger.kernel.org, 
	Kelly Rossmoyer <krossmo@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 19, 2024 at 11:38=E2=80=AFAM Thomas Gleixner <tglx@linutronix.d=
e> wrote:
>
> On Thu, Jan 18 2024 at 14:11, John Stultz wrote:
> >   I'm always a bit cautious when exposing stuff to userland,
> > particularly if it's potentially racy as you mentioned in your
> > description. One thought I had was might adding a similar check
> > earlier in the suspend path on the kernel side provide similar benefit
> > (without requiring userland changes)?
> >
> > Basically, if I understand the problem:
> > echo mem > /sys/power/state
> > <kernel goes through suspending everything>
> > alarmtimer_suspend()
> >   if (next_alarm < TWO_SECONDS)
> >       return -EBUSY;
> > <kernel has to resume everything, and all that time was wasted>
> >
> > So if instead we did:
> > echo mem > /sys/power/state
> > enter_state()
> >    if (alarmtimer_immenent())
> >       retrun -EBUSY
> >
> > So the kernel would come back much faster if the suspend was going to a=
bort.
> >
> > I suspect you all have considered this already but wanted to
> > understand what issues that approach has.
>
> It has the same race issues as the user space readout has as far as I
> understand and it's much simpler.
>
> Thanks,
>
>         tglx

Thanks John and Thomas for the suggestions!

The reason I did not go ahead with this approach previously was that I
wanted to contain the changes to the alarmtimer subsystem. I see the
benefit in eliminating the dependency on userspace reading from sysfs,
hence I shall work on v2 for this patch with an alternate solution
where I expose a function from alarmtimer to be used by the suspend
prepare flow in kernel/power.

Regards,
Pranav