All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suren Baghdasaryan <surenb@google.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Jason Xing <kerneljasonxing@linux.alibaba.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Dennis Zhou <dennis@kernel.org>,
	axboe@kernel.dk, lizefan@huawei.com, Tejun Heo <tj@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] psi: get poll_work to run when calling poll syscall next time
Date: Mon, 29 Jul 2019 09:27:20 -0700	[thread overview]
Message-ID: <CAJuCfpFsPn9MeS-pWcrAj1ZcVZXJNn94Vina6se2MgApgEFxHQ@mail.gmail.com> (raw)
In-Reply-To: <20190729152957.GA21958@cmpxchg.org>

On Mon, Jul 29, 2019 at 8:30 AM Johannes Weiner <hannes@cmpxchg.org> wrote:
>
> Hi Jason,
>
> On Tue, Jul 23, 2019 at 02:45:39PM +0800, Jason Xing wrote:
> > Only when calling the poll syscall the first time can user
> > receive POLLPRI correctly. After that, user always fails to
> > acquire the event signal.
> >
> > Reproduce case:
> > 1. Get the monitor code in Documentation/accounting/psi.txt
> > 2. Run it, and wait for the event triggered.
> > 3. Kill and restart the process.
> >
> > If the user doesn't kill the monitor process, it seems the
> > poll_work works fine. After killing and restarting the monitor,
> > the poll_work in kernel will never run again due to the wrong
> > value of poll_scheduled. Therefore, we should reset the value
> > as group_init() does after the last trigger is destroyed.
> >
> > Signed-off-by: Jason Xing <kerneljasonxing@linux.alibaba.com>
>
> Good catch, and the fix makes sense to me. However, it was a bit hard
> to understand how the problem occurs:
>
> > ---
> >  kernel/sched/psi.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
> > index 7acc632..66f4385 100644
> > --- a/kernel/sched/psi.c
> > +++ b/kernel/sched/psi.c
> > @@ -1133,6 +1133,12 @@ static void psi_trigger_destroy(struct kref *ref)
> >       if (kworker_to_destroy) {
> >               kthread_cancel_delayed_work_sync(&group->poll_work);
> >               kthread_destroy_worker(kworker_to_destroy);
> > +             /*
> > +              * The poll_work should have the chance to be put into the
> > +              * kthread queue when calling poll syscall next time. So
> > +              * reset poll_scheduled to zero as group_init() does
> > +              */
> > +             atomic_set(&group->poll_scheduled, 0);
>
> The question is why we can end up with poll_scheduled = 1 but the work
> not running (which would reset it to 0). And the answer is because the
> scheduling side sees group->poll_kworker under RCU protection and then
> schedules it, but here we cancel the work and destroy the worker. The
> cancel needs to pair with resetting the poll_scheduled flag:
>
>         if (kworker_to_destroy) {
>                 /*
>                  * After the RCU grace period has expired, the worker
>                  * can no longer be found through group->poll_kworker.
>                  * But it might have been already scheduled before
>                  * that - deschedule it cleanly before destroying it.
>                  */
>                 kthread_cancel_delayed_work_sync(&group->poll_work);
>                 atomic_set(&group->poll_scheduled, 0);
>
>                 kthread_destroy_worker(kworker_to_destroy);
>         }
>
> With that change, please add:
>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
>
> Thanks!

The changes makes sense to me as well. Thanks!

Reviewed-by: Suren Baghdasaryan <surenb@google.com>

  reply	other threads:[~2019-07-29 16:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-23  6:45 [PATCH] psi: get poll_work to run when calling poll syscall next time Jason Xing
2019-07-23 10:02 ` Caspar Zhang
2019-07-29  8:12 ` Jason Xing
2019-07-29 15:29 ` Johannes Weiner
2019-07-29 16:27   ` Suren Baghdasaryan [this message]
2019-07-30  5:16 ` [PATCH v2] " Jason Xing
2019-08-02  6:20   ` Jason Xing
2019-08-15  1:59   ` Jason Xing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJuCfpFsPn9MeS-pWcrAj1ZcVZXJNn94Vina6se2MgApgEFxHQ@mail.gmail.com \
    --to=surenb@google.com \
    --cc=axboe@kernel.dk \
    --cc=dennis@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kerneljasonxing@linux.alibaba.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.