On 08/01, Paul E. McKenney wrote:
>
> On Fri, Aug 01, 2014 at 05:53:10PM +0200, Oleg Nesterov wrote:
> > On 07/30, Paul E. McKenney wrote:
> > >
> > > + rcu_read_lock();
> > > + for_each_process_thread(g, t) {
> > > + if (t != current && ACCESS_ONCE(t->on_rq) &&
> >
On Fri, Aug 01, 2014 at 05:53:10PM +0200, Oleg Nesterov wrote:
> On 07/30, Paul E. McKenney wrote:
> >
> > + rcu_read_lock();
> > + for_each_process_thread(g, t) {
> > + if (t != current && ACCESS_ONCE(t->on_rq) &&
> > + !is_idle_task(t))
On 07/30, Paul E. McKenney wrote:
>
> + rcu_read_lock();
> + for_each_process_thread(g, t) {
> + if (t != current && ACCESS_ONCE(t->on_rq) &&
> + !is_idle_task(t)) {
> + t->rcu_tasks_nvcsw =
On 07/30, Paul E. McKenney wrote:
+ rcu_read_lock();
+ for_each_process_thread(g, t) {
+ if (t != current ACCESS_ONCE(t-on_rq)
+ !is_idle_task(t)) {
+ t-rcu_tasks_nvcsw = ACCESS_ONCE(t-nvcsw);
On Fri, Aug 01, 2014 at 05:53:10PM +0200, Oleg Nesterov wrote:
On 07/30, Paul E. McKenney wrote:
+ rcu_read_lock();
+ for_each_process_thread(g, t) {
+ if (t != current ACCESS_ONCE(t-on_rq)
+ !is_idle_task(t)) {
+
On 08/01, Paul E. McKenney wrote:
On Fri, Aug 01, 2014 at 05:53:10PM +0200, Oleg Nesterov wrote:
On 07/30, Paul E. McKenney wrote:
+ rcu_read_lock();
+ for_each_process_thread(g, t) {
+ if (t != current ACCESS_ONCE(t-on_rq)
+
On Fri, Aug 01, 2014 at 08:53:38AM +0800, Lai Jiangshan wrote:
> On 08/01/2014 12:09 AM, Paul E. McKenney wrote:
>
> >
> >>> + /*
> >>> + * There were callbacks, so we need to wait for an
> >>> + * RCU-tasks grace period. Start off by scanning
> >>> + * the
On 08/01/2014 12:09 AM, Paul E. McKenney wrote:
>
>>> + /*
>>> +* There were callbacks, so we need to wait for an
>>> +* RCU-tasks grace period. Start off by scanning
>>> +* the task list for tasks that are not already
>>> +* voluntarily
On Thu, Jul 31, 2014 at 07:27:52PM +0200, Oleg Nesterov wrote:
> On 07/31, Paul E. McKenney wrote:
> >
> > On Thu, Jul 31, 2014 at 06:31:38PM +0200, Oleg Nesterov wrote:
> >
> > > But can't we avoid get_task_struct()? This can pin a lot of task_struct's.
> > > Can't we just add
On 07/31, Paul E. McKenney wrote:
>
> On Thu, Jul 31, 2014 at 06:31:38PM +0200, Oleg Nesterov wrote:
>
> > But can't we avoid get_task_struct()? This can pin a lot of task_struct's.
> > Can't we just add list_del_rcu(holdout_list) into __unhash_process() ?
>
> If I add the list_del_rcu() there,
On Thu, Jul 31, 2014 at 06:31:38PM +0200, Oleg Nesterov wrote:
> Again, sorry, I didn't read the patches yet, just noticed your discussion...
>
> On 07/31, Paul E. McKenney wrote:
> >
> > On Thu, Jul 31, 2014 at 03:30:12PM +0800, Lai Jiangshan wrote:
> >
> > > > +
On Thu, Jul 31, 2014 at 09:47:39AM -0700, Paul E. McKenney wrote:
> The idea here is to avoid having the kthread and to avoid providing
> callbacks, but to instead do the work currently done by the kthread
> in a synchronous function called by the updater?
yep.
> My concern with this approach
On Thu, Jul 31, 2014 at 06:20:30PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 31, 2014 at 09:09:24AM -0700, Paul E. McKenney wrote:
> > Well, that is one of the questions in the 0/10 cover letter. If it turns
> > out to be necessary to worry about idle-task trampolines, it should be
> > possible
Again, sorry, I didn't read the patches yet, just noticed your discussion...
On 07/31, Paul E. McKenney wrote:
>
> On Thu, Jul 31, 2014 at 03:30:12PM +0800, Lai Jiangshan wrote:
>
> > > + t->rcu_tasks_nvcsw = ACCESS_ONCE(t->nvcsw);
> > > +
On Thu, Jul 31, 2014 at 09:09:24AM -0700, Paul E. McKenney wrote:
> Well, that is one of the questions in the 0/10 cover letter. If it turns
> out to be necessary to worry about idle-task trampolines, it should be
> possible to avoid hammering all idle CPUs in the common case. Though maybe
>
On Thu, Jul 31, 2014 at 03:30:12PM +0800, Lai Jiangshan wrote:
> On 07/31/2014 08:39 AM, Paul E. McKenney wrote:
> > From: "Paul E. McKenney"
> >
> > This commit adds a new RCU-tasks flavor of RCU, which provides
> > call_rcu_tasks(). This RCU flavor's quiescent states are voluntary
> > context
On 07/31/2014 08:39 AM, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit adds a new RCU-tasks flavor of RCU, which provides
> call_rcu_tasks(). This RCU flavor's quiescent states are voluntary
> context switch (not preemption!), userspace execution, and the idle loop.
> Note
On 07/31/2014 08:39 AM, Paul E. McKenney wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
This commit adds a new RCU-tasks flavor of RCU, which provides
call_rcu_tasks(). This RCU flavor's quiescent states are voluntary
context switch (not preemption!), userspace execution, and the
On Thu, Jul 31, 2014 at 03:30:12PM +0800, Lai Jiangshan wrote:
On 07/31/2014 08:39 AM, Paul E. McKenney wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
This commit adds a new RCU-tasks flavor of RCU, which provides
call_rcu_tasks(). This RCU flavor's quiescent states are
On Thu, Jul 31, 2014 at 09:09:24AM -0700, Paul E. McKenney wrote:
Well, that is one of the questions in the 0/10 cover letter. If it turns
out to be necessary to worry about idle-task trampolines, it should be
possible to avoid hammering all idle CPUs in the common case. Though maybe
Again, sorry, I didn't read the patches yet, just noticed your discussion...
On 07/31, Paul E. McKenney wrote:
On Thu, Jul 31, 2014 at 03:30:12PM +0800, Lai Jiangshan wrote:
+ t-rcu_tasks_nvcsw = ACCESS_ONCE(t-nvcsw);
+ t-rcu_tasks_holdout
On Thu, Jul 31, 2014 at 06:20:30PM +0200, Peter Zijlstra wrote:
On Thu, Jul 31, 2014 at 09:09:24AM -0700, Paul E. McKenney wrote:
Well, that is one of the questions in the 0/10 cover letter. If it turns
out to be necessary to worry about idle-task trampolines, it should be
possible to
On Thu, Jul 31, 2014 at 09:47:39AM -0700, Paul E. McKenney wrote:
The idea here is to avoid having the kthread and to avoid providing
callbacks, but to instead do the work currently done by the kthread
in a synchronous function called by the updater?
yep.
My concern with this approach is
On Thu, Jul 31, 2014 at 06:31:38PM +0200, Oleg Nesterov wrote:
Again, sorry, I didn't read the patches yet, just noticed your discussion...
On 07/31, Paul E. McKenney wrote:
On Thu, Jul 31, 2014 at 03:30:12PM +0800, Lai Jiangshan wrote:
+
On 07/31, Paul E. McKenney wrote:
On Thu, Jul 31, 2014 at 06:31:38PM +0200, Oleg Nesterov wrote:
But can't we avoid get_task_struct()? This can pin a lot of task_struct's.
Can't we just add list_del_rcu(holdout_list) into __unhash_process() ?
If I add the list_del_rcu() there, then I am
On Thu, Jul 31, 2014 at 07:27:52PM +0200, Oleg Nesterov wrote:
On 07/31, Paul E. McKenney wrote:
On Thu, Jul 31, 2014 at 06:31:38PM +0200, Oleg Nesterov wrote:
But can't we avoid get_task_struct()? This can pin a lot of task_struct's.
Can't we just add list_del_rcu(holdout_list) into
On 08/01/2014 12:09 AM, Paul E. McKenney wrote:
+ /*
+* There were callbacks, so we need to wait for an
+* RCU-tasks grace period. Start off by scanning
+* the task list for tasks that are not already
+* voluntarily blocked. Mark
On Fri, Aug 01, 2014 at 08:53:38AM +0800, Lai Jiangshan wrote:
On 08/01/2014 12:09 AM, Paul E. McKenney wrote:
+ /*
+ * There were callbacks, so we need to wait for an
+ * RCU-tasks grace period. Start off by scanning
+ * the task list for tasks
From: "Paul E. McKenney"
This commit adds a new RCU-tasks flavor of RCU, which provides
call_rcu_tasks(). This RCU flavor's quiescent states are voluntary
context switch (not preemption!), userspace execution, and the idle loop.
Note that unlike other RCU flavors, these quiescent states occur
From: Paul E. McKenney paul...@linux.vnet.ibm.com
This commit adds a new RCU-tasks flavor of RCU, which provides
call_rcu_tasks(). This RCU flavor's quiescent states are voluntary
context switch (not preemption!), userspace execution, and the idle loop.
Note that unlike other RCU flavors, these
30 matches
Mail list logo
