linux-kernel - Re: [RFC][PATCH 4/4] Rename lock_cpu_hotplug/unlock_cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20060830181347.GF1296@us.ibm.com>
Date:	Wed, 30 Aug 2006 11:13:47 -0700
From:	"Paul E. McKenney" <paulmck@...ibm.com>
To:	Paul Jackson <pj@....com>
Cc:	ego@...ibm.com, mingo@...e.hu, nickpiggin@...oo.com.au,
	arjan@...radead.org, rusty@...tcorp.com.au, torvalds@...l.org,
	akpm@...l.org, linux-kernel@...r.kernel.org, arjan@...el.linux.com,
	davej@...hat.com, dipankar@...ibm.com, vatsa@...ibm.com,
	ashok.raj@...el.com, josht@...ibm.com
Subject: Re: [RFC][PATCH 4/4] Rename lock_cpu_hotplug/unlock_cpu_hotplug

On Wed, Aug 30, 2006 at 10:54:34AM -0700, Paul Jackson wrote:
> Paul E. McKenney wrote:
> > Well, my next question was going to be whether cpuset readers really
> > need to exclude the writers, or whether there can be a transition
> > period while the mastodon makes the change as long as it avoids stomping
> > the locusts.  ;-)
> 
> The mastodon's (aka mammoths ;) may make a batch of several related
> changes to the cpuset configuration.  What's important is that the
> locusts see either none or all of the changes in a given batch, not
> some intermediate inconsistent state, and that the locusts see the
> change batches in the same order they were applied.
> 
> Off the top of my head, I doubt I care when the locusts see the
> changes.  Some delay is ok, if that's your question.
> 
> But don't try too hard to fit any work you do to cpusets.  For now,
> I don't plan to mess with cpuset locking anytime soon.  And when I
> do next, it might be that all I need to do is to change the quick
> lock held by the locusts from a mutex to an ordinary rwsem, so that
> multiple readers (locusts) can access the cpuset configuration in
> parallel.

Sounds like a job for RCU (if locusts never sleep in critical sections)
or SRCU (if locusts do block).  ;-)  Seriously, this would get you
deterministic read-side acquisition overhead.  And very low overhead
at that -- no memory barriers, cache misses, or atomic instructions
in the common case of no mammoths/mastodons.

That said, I am not familiar enough with cpusets to know if there are
any gotchas in making the change appear atomic.  The usual approach
is to link updates in, so that readers either see the new state or
do not, but don't see any intermediate states.  I would guess that
updates sometimes involve moving resources from one set to another,
and that such moves must be atomic in the "mv" command sense.  There
are some reasonably straightforward ways of making this happen.

							Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/