On Fri, Apr 26, 2013 at 08:15:34AM +0200, Ingo Molnar wrote:
>
> * Simon Horman wrote:
>
> > This avoids the situation where a dump of a large number of connections
> > may prevent scheduling for a long time while also avoiding excessive
> > calls to rcu_read_unlock() and rcu_read_lock().
> >
>
Hello,
On Mon, 29 Apr 2013, Paul E. McKenney wrote:
> On Tue, Apr 30, 2013 at 12:08:18AM +0300, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Sat, 27 Apr 2013, Paul E. McKenney wrote:
> >
> > > I would instead suggest something like:
> > >
> > > #ifndef CONFIG_PREEMPT_RCU
> >
On Tue, Apr 30, 2013 at 12:08:18AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Sat, 27 Apr 2013, Paul E. McKenney wrote:
>
> > On Sat, Apr 27, 2013 at 02:32:48PM +0300, Julian Anastasov wrote:
> > >
> > > So, I assume, to help realtime kernels and rcu_barrier
> > > it is not a good
Hello,
On Sat, 27 Apr 2013, Paul E. McKenney wrote:
> On Sat, Apr 27, 2013 at 02:32:48PM +0300, Julian Anastasov wrote:
> >
> > So, I assume, to help realtime kernels and rcu_barrier
> > it is not a good idea to guard rcu_read_unlock with checks.
> > I see that rcu_read_unlock will
On Sat, Apr 27, 2013 at 02:32:48PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Fri, 26 Apr 2013, Eric Dumazet wrote:
>
> > On Fri, 2013-04-26 at 10:48 -0700, Paul E. McKenney wrote:
> >
> > > Don't get me wrong, I am not opposing cond_resched_rcu_lock() because it
> > > will be diffi
On Sat, Apr 27, 2013 at 09:18:15AM +0200, Peter Zijlstra wrote:
> > In the worst case, I
> > can fire up a prio 99 kthread on each CPU and send that kthread a
> > wakeup from RCU's rcu_gp_fqs() code.
>
> You just know that's going to be _so_ popular ;-)
;-) ;-) ;-)
I must confess that I would pr
Hello,
On Fri, 26 Apr 2013, Eric Dumazet wrote:
> On Fri, 2013-04-26 at 10:48 -0700, Paul E. McKenney wrote:
>
> > Don't get me wrong, I am not opposing cond_resched_rcu_lock() because it
> > will be difficult to validate. For one thing, until there are a lot of
> > them, manual inspec
> In the worst case, I
> can fire up a prio 99 kthread on each CPU and send that kthread a
> wakeup from RCU's rcu_gp_fqs() code.
You just know that's going to be _so_ popular ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
On Fri, Apr 26, 2013 at 11:26:55AM -0700, Eric Dumazet wrote:
> On Fri, 2013-04-26 at 10:48 -0700, Paul E. McKenney wrote:
>
> > Don't get me wrong, I am not opposing cond_resched_rcu_lock() because it
> > will be difficult to validate. For one thing, until there are a lot of
> > them, manual ins
On Fri, 2013-04-26 at 10:48 -0700, Paul E. McKenney wrote:
> Don't get me wrong, I am not opposing cond_resched_rcu_lock() because it
> will be difficult to validate. For one thing, until there are a lot of
> them, manual inspection is quite possible. So feel free to apply my
> Acked-by to the p
On Fri, Apr 26, 2013 at 07:19:49PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 26, 2013 at 08:45:47AM -0700, Paul E. McKenney wrote:
> > On Fri, Apr 26, 2013 at 10:03:13AM +0200, Peter Zijlstra wrote:
> > > On Fri, Apr 26, 2013 at 10:45:08AM +0900, Simon Horman wrote:
> > >
> > > > @@ -975,8 +975,7
On Fri, Apr 26, 2013 at 08:45:47AM -0700, Paul E. McKenney wrote:
> On Fri, Apr 26, 2013 at 10:03:13AM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 26, 2013 at 10:45:08AM +0900, Simon Horman wrote:
> >
> > > @@ -975,8 +975,7 @@ static void *ip_vs_conn_array(struct seq_file *seq,
> > > loff_t pos)
On Fri, Apr 26, 2013 at 08:59:07AM -0700, Eric Dumazet wrote:
> On Fri, 2013-04-26 at 08:45 -0700, Paul E. McKenney wrote:
>
> > I have done some crude coccinelle patterns in the past, but they are
> > subject to false positives (from when you transfer the pointer from
> > RCU protection to refere
On Fri, 2013-04-26 at 08:45 -0700, Paul E. McKenney wrote:
> I have done some crude coccinelle patterns in the past, but they are
> subject to false positives (from when you transfer the pointer from
> RCU protection to reference-count protection) and also false negatives
> (when you atomically in
On Fri, Apr 26, 2013 at 10:03:13AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 26, 2013 at 10:45:08AM +0900, Simon Horman wrote:
>
> > @@ -975,8 +975,7 @@ static void *ip_vs_conn_array(struct seq_file *seq,
> > loff_t pos)
> > return cp;
> > }
> >
On Fri, Apr 26, 2013 at 10:45:08AM +0900, Simon Horman wrote:
> @@ -975,8 +975,7 @@ static void *ip_vs_conn_array(struct seq_file *seq,
> loff_t pos)
> return cp;
> }
> }
> - rcu_read_unlock();
> - rcu_read_
* Simon Horman wrote:
> This avoids the situation where a dump of a large number of connections
> may prevent scheduling for a long time while also avoiding excessive
> calls to rcu_read_unlock() and rcu_read_lock().
>
> Cc: Eric Dumazet
> Cc: Julian Anastasov
> Signed-off-by: Simon Horman
>
This avoids the situation where a dump of a large number of connections
may prevent scheduling for a long time while also avoiding excessive
calls to rcu_read_unlock() and rcu_read_lock().
Cc: Eric Dumazet
Cc: Julian Anastasov
Signed-off-by: Simon Horman
---
net/netfilter/ipvs/ip_vs_conn.c | 6
18 matches
Mail list logo
