lkml.org 
[lkml]   [2006]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/11] Task watchers: Introduction
Matt Helsley wrote:
> On Wed, 2006-06-21 at 21:41 +1000, Peter Williams wrote:
>> Peter Williams wrote:
>>> Matt Helsley wrote:
>>>> On Wed, 2006-06-21 at 15:41 +1000, Peter Williams wrote:
>>>>> On a related note, I can't see where the new task's notify field gets
>>>>> initialized during fork.
>>>> It's initialized in kernel/sys.c:notify_per_task_watchers(), which calls
>>>> RAW_INIT_NOTIFIER_HEAD(&task->notify) in response to WATCH_TASK_INIT.
>>> I think that's too late. It needs to be done at the start of
>>> notify_watchers() before any other watchers are called for the new task.
>
> I don't see why you think it's too late. It needs to be initialized
> before it's used. Waiting until notify_per_task_watchers() is called
> with WATCH_TASK_INIT does this.

I probably didn't understand the code well enough. I'm still learning
how it all hangs together :-).

>
>> On second thoughts, it would simpler just before the WATCH_TASK_INIT
>> call in copy_process() in fork.c. It can be done unconditionally there.
>>
>> Peter
>
> That would work. It would not simplify the control flow of the code.
> The branch for WATCH_TASK_INIT in notify_per_task_watchers() is
> unavoidable; we need to call the parent task's chain in that case since
> we know the child task's is empty.
>
> It is also counter to one goal of the patches -- reducing the "clutter"
> in these paths. Arguably task watchers is the same kind of clutter that
> existed before. However, it is a means of factoring such clutter into
> fewer instances (ideally one) of the pattern.

Maybe a few comments in the code to help reviewers such as me learn how
it works more quickly would be worthwhile.

BTW as a former user of PAGG, I think there are ideas in the PAGG
implementation that you should look at. In particular:

1. The use of an array of function pointers (one for each hook) can cut
down on the overhead. The notifier_block only needs to contain a
pointer to the array so there's no increase in the size of that
structure. Within the array a null pointer would mean "don't bother
calling". Only one real array needs to exist even for per task as
they're all using the same functions (just separate data). It removes
the need for a switch statement in the client's function as well as
saving on unnecessary function calls.

2. A helper mechanism to allow a client that's being loaded as a module
to visit all existing tasks and do whatever initialization it needs to
do. Without this every client would have to implement such a mechanism
themselves (and it's not pretty).

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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