On Wed, Oct 02, 2013 at 05:49:01PM +0200, Oleg Nesterov wrote:
> On 10/02, Peter Zijlstra wrote:
> >
> > From: Oleg Nesterov
>
> Thanks! I was writing the patch, and I chose almost the same naming ;)
>
> > Signed-off-by: Peter Zijlstra
>
> Signed-off-by: Oleg Nesterov
>
> In fact I'd like to
On 10/04, Peter Zijlstra wrote:
>
> On Fri, Oct 04, 2013 at 09:06:53PM +0200, Oleg Nesterov wrote:
> > However, yes-yes-yes, I do think that we need the non-exclusive mode
> > too, at least for percpu_down_write_nonexclusive() which I think we
> > need as well.
>
> I just need to disagree with the
On Fri, Oct 04, 2013 at 09:06:53PM +0200, Oleg Nesterov wrote:
> However, yes-yes-yes, I do think that we need the non-exclusive mode
> too, at least for percpu_down_write_nonexclusive() which I think we
> need as well.
I just need to disagree with the write_nonexclusive() name; the
construct I qu
On 10/04, Peter Zijlstra wrote:
>
> On Fri, Oct 04, 2013 at 05:13:23PM +0200, Oleg Nesterov wrote:
>
> > I am not trying saying this feature is "must have", of course it
> > is not. The only problem, I am a bit puzzled why you dislike it
> > that much.
>
> The reason I dislike it is because I feel
On Fri, Oct 04, 2013 at 05:13:23PM +0200, Oleg Nesterov wrote:
> Not sure I understand...
>
> percpu-rwsem will use exclusive mode, with or without the possible
> improvements we can copy from cpuhp. sb_writers can probably use it
> too (along with other helpers from percpu-rwsem we do not have ye
On Fri, Oct 04, 2013 at 01:29:45PM +0200, Oleg Nesterov wrote:
> On 10/03, Paul E. McKenney wrote:
> >
> > On Thu, Oct 03, 2013 at 11:10:09PM +0200, Oleg Nesterov wrote:
> > >
> > > rcusync: introduce rcu_sync_struct->exclusive mode
> > >
> > > CHANGELOG.
> >
> > Should the changelog really be in a
On 10/04, Peter Zijlstra wrote:
>
> On Fri, Oct 04, 2013 at 03:31:35PM +0200, Oleg Nesterov wrote:
> > > I'm really starting to think we shouldn't do this in rcu_sync at all.
> >
> > I do not really understand why you insist that rcu_sync() should not
> > try to help to the users which need the exc
On Fri, Oct 04, 2013 at 03:31:35PM +0200, Oleg Nesterov wrote:
> > I'm really starting to think we shouldn't do this in rcu_sync at all.
>
> I do not really understand why you insist that rcu_sync() should not
> try to help to the users which need the exclusive mode.
But what other users; you you
On 10/04, Peter Zijlstra wrote:
>
> On Fri, Oct 04, 2013 at 02:13:00PM +0200, Oleg Nesterov wrote:
> > On 10/04, Peter Zijlstra wrote:
> > >
> > > I'm not entirely sure what the advantage is of having that logic in this
> > > primitive. Shouldn't that be something the user of this rcu_sync stuff
>
On Fri, Oct 04, 2013 at 02:13:00PM +0200, Oleg Nesterov wrote:
> On 10/04, Peter Zijlstra wrote:
> >
> > On Fri, Oct 04, 2013 at 01:15:13PM +0200, Oleg Nesterov wrote:
> > > > What's exclusive to mean? One writer at a time?
> > >
> > > Yes,
> >
> > I'm not entirely sure what the advantage is of hav
On 10/04, Peter Zijlstra wrote:
>
> On Fri, Oct 04, 2013 at 01:15:13PM +0200, Oleg Nesterov wrote:
> > > What's exclusive to mean? One writer at a time?
> >
> > Yes,
>
> I'm not entirely sure what the advantage is of having that logic in this
> primitive. Shouldn't that be something the user of thi
On 10/04, Peter Zijlstra wrote:
>
> On Fri, Oct 04, 2013 at 01:15:13PM +0200, Oleg Nesterov wrote:
> > Of course we can fix this, but wait_for_completion/complete already
> > does the necessary work: x->done acts as a resource counter which is
> > always checked/incremented/decremented under the sa
On Fri, Oct 04, 2013 at 01:15:13PM +0200, Oleg Nesterov wrote:
> > What's exclusive to mean? One writer at a time?
>
> Yes,
I'm not entirely sure what the advantage is of having that logic in this
primitive. Shouldn't that be something the user of this rcu_sync stuff
does (or not) depending on it
On Fri, Oct 04, 2013 at 01:15:13PM +0200, Oleg Nesterov wrote:
> Of course we can fix this, but wait_for_completion/complete already
> does the necessary work: x->done acts as a resource counter which is
> always checked/incremented/decremented under the same lock.
Urgh, so now you're not using a
On 10/03, Paul E. McKenney wrote:
>
> On Thu, Oct 03, 2013 at 11:10:09PM +0200, Oleg Nesterov wrote:
> >
> > rcusync: introduce rcu_sync_struct->exclusive mode
> >
> > CHANGELOG.
>
> Should the changelog really be in all caps? (Sorry, couldn't resist...)
Apparently you do not realize it is going
On 10/04, Peter Zijlstra wrote:
>
> On Thu, Oct 03, 2013 at 11:10:09PM +0200, Oleg Nesterov wrote:
> > On 10/03, Oleg Nesterov wrote:
> > >
> > > So unless Peter objects I'll write the changelogs (always nontrivial
> > > task),
> > > test, and send these 2 patches + "add ops->barr() / rcu_sync_wai
On Thu, Oct 03, 2013 at 11:10:09PM +0200, Oleg Nesterov wrote:
> On 10/03, Oleg Nesterov wrote:
> >
> > So unless Peter objects I'll write the changelogs (always nontrivial task),
> > test, and send these 2 patches + "add ops->barr() / rcu_sync_wait_for_cb"
> > tomorrow.
>
> And, can't resist, pro
On Thu, Oct 03, 2013 at 10:00:02PM +0200, Oleg Nesterov wrote:
> On 10/03, Paul E. McKenney wrote:
> >
> > On Thu, Oct 03, 2013 at 09:33:19PM +0200, Oleg Nesterov wrote:
> > > On 10/03, Oleg Nesterov wrote:
> > > >
> > > > Because I believe this needs another patch ;) see below, didn't test
> > > >
On Thu, Oct 03, 2013 at 10:14:57PM +0200, Paolo Bonzini wrote:
> Do you need to do the same in rcu_sync_init?
Yes.. I actually did but only send the diff for the header file :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ker
On Thu, Oct 03, 2013 at 11:10:09PM +0200, Oleg Nesterov wrote:
> On 10/03, Oleg Nesterov wrote:
> >
> > So unless Peter objects I'll write the changelogs (always nontrivial task),
> > test, and send these 2 patches + "add ops->barr() / rcu_sync_wait_for_cb"
> > tomorrow.
>
> And, can't resist, pro
On 10/03, Oleg Nesterov wrote:
>
> So unless Peter objects I'll write the changelogs (always nontrivial task),
> test, and send these 2 patches + "add ops->barr() / rcu_sync_wait_for_cb"
> tomorrow.
And, can't resist, probably another patch below (incomplete, needs the
obvious change in cpu.c and
Il 03/10/2013 20:40, Peter Zijlstra ha scritto:
> On Thu, Oct 03, 2013 at 09:41:17AM -0700, Paul E. McKenney wrote:
>> On Wed, Oct 02, 2013 at 04:56:57PM +0200, Peter Zijlstra wrote:
>> #ifdef CONFIG_PROVE_RCU
>> #define rcu_sync_is_idle_check(rss) BUG_ON(!rss->read_side_check())
>> #else
>> #defin
On 10/03, Paul E. McKenney wrote:
>
> On Thu, Oct 03, 2013 at 09:33:19PM +0200, Oleg Nesterov wrote:
> > On 10/03, Oleg Nesterov wrote:
> > >
> > > Because I believe this needs another patch ;) see below, didn't test
> > > it yet.
> > > ...
> > > struct rcu_sync_ops {
> > > void (*sync)(void);
>
On Thu, Oct 03, 2013 at 09:33:19PM +0200, Oleg Nesterov wrote:
> On 10/03, Oleg Nesterov wrote:
> >
> > Because I believe this needs another patch ;) see below, didn't test
> > it yet.
> > ...
> > struct rcu_sync_ops {
> > void (*sync)(void);
> > void (*call)(struct rcu_head *, void (*)(st
On 10/03, Oleg Nesterov wrote:
>
> Because I believe this needs another patch ;) see below, didn't test
> it yet.
> ...
> struct rcu_sync_ops {
> void (*sync)(void);
> void (*call)(struct rcu_head *, void (*)(struct rcu_head *));
> +#ifdef CONFIG_PROVE_RCU
> + bool (*held)(void);
On 10/03, Paul E. McKenney wrote:
>
> On Thu, Oct 03, 2013 at 08:47:19PM +0200, Oleg Nesterov wrote:
> >
> > Yes, but...
> >
> > I think it would be better to start with the patch below, this way
> > it would be easier a) to add the new ops (we need more anyway) and b)
> > use CONFIG_PROVE_RCU to a
On Thu, Oct 03, 2013 at 08:47:19PM +0200, Oleg Nesterov wrote:
> On 10/03, Peter Zijlstra wrote:
> >
> > On Thu, Oct 03, 2013 at 09:41:17AM -0700, Paul E. McKenney wrote:
> > > On Wed, Oct 02, 2013 at 04:56:57PM +0200, Peter Zijlstra wrote:
> > > #ifdef CONFIG_PROVE_RCU
> > > #define rcu_sync_is_id
On 10/03, Peter Zijlstra wrote:
>
> On Thu, Oct 03, 2013 at 09:41:17AM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 02, 2013 at 04:56:57PM +0200, Peter Zijlstra wrote:
> > #ifdef CONFIG_PROVE_RCU
> > #define rcu_sync_is_idle_check(rss) BUG_ON(!rss->read_side_check())
> > #else
> > #define rcu_syn
On Thu, Oct 03, 2013 at 08:40:01PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 03, 2013 at 09:41:17AM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 02, 2013 at 04:56:57PM +0200, Peter Zijlstra wrote:
> > #ifdef CONFIG_PROVE_RCU
> > #define rcu_sync_is_idle_check(rss) BUG_ON(!rss->read_side_check())
On Thu, Oct 03, 2013 at 09:41:17AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 02, 2013 at 04:56:57PM +0200, Peter Zijlstra wrote:
> #ifdef CONFIG_PROVE_RCU
> #define rcu_sync_is_idle_check(rss) BUG_ON(!rss->read_side_check())
> #else
> #define rcu_sync_is_idle_check(rss) do { } while (0)
> #endif
On Thu, Oct 03, 2013 at 07:00:52PM +0200, Oleg Nesterov wrote:
> On 10/03, Paul E. McKenney wrote:
> >
> > How about the something like the following, where ->read_side_check()
> > gets rcu_read_lock_held(), rcu_read_lock_bh_held(), or
> > rcu_read_lock_sched_held(), as appropriate?
> >
> > #ifdef
On 10/03, Paul E. McKenney wrote:
>
> How about the something like the following, where ->read_side_check()
> gets rcu_read_lock_held(), rcu_read_lock_bh_held(), or
> rcu_read_lock_sched_held(), as appropriate?
>
> #ifdef CONFIG_PROVE_RCU
> #define rcu_sync_is_idle_check(rss) BUG_ON(!rss->read_side
On Wed, Oct 02, 2013 at 05:49:01PM +0200, Oleg Nesterov wrote:
> On 10/02, Peter Zijlstra wrote:
> >
> > From: Oleg Nesterov
>
> Thanks! I was writing the patch, and I chose almost the same naming ;)
>
> > Signed-off-by: Peter Zijlstra
>
> Signed-off-by: Oleg Nesterov
>
> In fact I'd like to
On Wed, Oct 02, 2013 at 04:56:57PM +0200, Peter Zijlstra wrote:
> From: Oleg Nesterov
>
> It is functionally equivalent to
>
> struct xxx_struct {
> atomic_t counter;
> };
>
> static inline bool xxx_is_idle(struct xxx_struct *xxx)
> {
>
On 10/02, Peter Zijlstra wrote:
>
> From: Oleg Nesterov
Thanks! I was writing the patch, and I chose almost the same naming ;)
> Signed-off-by: Peter Zijlstra
Signed-off-by: Oleg Nesterov
In fact I'd like to add my sob to 1/3 and 3/3 as well.
Paul, to remind, this is only the first step. I
From: Oleg Nesterov
It is functionally equivalent to
struct xxx_struct {
atomic_t counter;
};
static inline bool xxx_is_idle(struct xxx_struct *xxx)
{
return atomic_read(&xxx->counter) == 0;
}
static inline void xx
36 matches
Mail list logo
