lkml.org 
[lkml]   [2010]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 03/10] ftrace: Drop the ftrace_profile_enabled checks in tracing hot path
From
Date
On Fri, 2010-01-22 at 03:43 +0100, Frederic Weisbecker wrote:

> > Now for the reason I Cc'd Paul and Mathieu...
> >
> > If we had a synchronize_sched() like function that would wait and return
> > when all preempted tasks have been scheduled again and went to either
> > userspace or called schedule directly, then we could actually do this.
> >
> > After unregistering the function graph trace, you call this
> > "synchronize_tasks()" and it will guarantee that all currently preempted
> > tasks have either went to userspace or have called schedule() directly.
> > Then it would be safe to remove this check.
>
>
>
> Good point!
>
> I fear that would require heavy hooks in the scheduler though...
>

Not a heavy one. We could add a field to the task_struct and just call
something if it is set.


At start of schedule()

if (unlikely(current->pcount))
handle_pcount_waiters(current);


void handle_pcount_waiters(struct task_struct *p)
{
current->pcount = 0;
wake_up(pcount_waiters);
}


and for the synchronize_tasks(), just search the task list for tasks
that are on the run queue but not running, and add a pcount timestamp
and record the list of tasks (allocated list).

After it is woken up, it checks the list of tasks and if a task does not
have the pcount timestamp that matches what was stored, it removes it
from the list. When it is finally woken up and does not have any more
tasks on the list, it continues.

This is just a basic idea, i left out a bunch of details, but I'm sure
it is feasible. This type of wait may work for other types of lockless
algorithms too.

-- Steve





\
 
 \ /
  Last update: 2010-01-22 04:07    [W:0.116 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site