mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pierre Habouzit <pierre.habouzit@intersec.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, Avi Kivity <avi@qumranet.com>,
	Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] sched: allow preempt notifiers to self-unregister.
Date: Fri, 16 Dec 2011 18:25:23 +0100	[thread overview]
Message-ID: <20111216172523.GB4569@madism.org> (raw)
In-Reply-To: <1324055385.18942.109.camel@twins>

On Fri, Dec 16, 2011 at 06:09:45PM +0100, Peter Zijlstra wrote:
> On Fri, 2011-12-16 at 17:15 +0100, Pierre Habouzit wrote:
> 
> >   As a background, this need is because I have some kind of module code
> >   that uses this facility to evaluate how many of a group of threads are
> >   concurrently running (to regulate a pool of threads).
> 
> Typically such stuff is only merged along with whomever uses it.

Well for now I'm just toying with it, it's nowhere nead to be ready to
be even shown without me having to bury my head from shame ;)

> >   Hence I install those callbacks for the thread registering themselves
> >   and want to keep them until the thread dies. Sadly I have no way to
> >   unregister those callbacks right now, but for horrible hacks (involving
> >   private delayed queues processed regularly walked to kfree() the
> >   structures referencing pids that are dead, urgh).
> 
> kfree_rcu() is the 'normal' way to cheat your way out of this.

Hmm, if when I'm scheduled "out" with the TASK_DEAD bit set, am I sure
the _in/_out callback will never ever be called again?

It experimentally seems that the answer is yes, but I'm not familiar
enough with the scheduler to be a 100% sure. If yes then kfree_rcu is
just fine indeed and I don't need the patch, at all.

If it's not "sure" then I assume I can probably use call_rcu() but that
looks like a total overkill for something that can be fully avoided with
my patch, which incidentally, doesn't slow the typical sched path (there
should be no callbacks and the _safe iterator exits as fast as the non
safe iterator).
-- 
Intersec <http://www.intersec.com>
Pierre Habouzit <pierre.habouzit@intersec.com> | Chief Software Architect
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie

  reply	other threads:[~2011-12-16 17:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 16:15 Pierre Habouzit
2011-12-16 17:09 ` Peter Zijlstra
2011-12-16 17:25   ` Pierre Habouzit [this message]
2011-12-16 17:33     ` Peter Zijlstra
2011-12-16 17:42       ` Pierre Habouzit
2011-12-18  9:10 ` Avi Kivity
2011-12-19 10:26   ` Pierre Habouzit

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=20111216172523.GB4569@madism.org \
    --to=pierre.habouzit@intersec.com \
    --cc=avi@qumranet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®