Re: [patch] Minor PAGG attach/detach semantic change for 2.6.11

Hi,

> Hi.  I'm confused with the above paragraph.  My initial plan was only to
> convert how job uses pnotify to be rcu-aware.  So this mainly relates to
> the pnotify_subscriber_list.
> 
> job_dispatch_attachpid adds the kernel module as a subscriber to the given
> process.  It doesn't access the list directly but does (in my updated version)
> have the write lock held and the rcu_read_lock/unlock calls.  But it calls
> pnotify_subscribe to actually add the kernel module to the subscriber list
> of the task.
> 
> pnotify_subscribe uses list_add_tail_rcu to do this.

Ahh, It might be my misunderstandings.
Since the imeplementation of job does not allow to move a process from
one job to another one directly, The above-mentioned worry is useless.
When a process moves between jobs, job was detached at first. Right ?
Therefore, it's hidden by pnotify_subscribe(). OK.

> Maybe there are other examples that need adjustments?  On the download site,
> in pnotify-test, you'll see my first pass at an RCU versoin of pnotify.
> In job-test, you'll see a first cut at a rcu-pnotify version of Job.

Now, I'm trying to read your new pnotify/job patch in this morning.


>>When anyone tries to associate a job with a running multithread-process,
>>it's required to scan for each thread in this process under
>>read_lock(&tasklist_lock), because job is an aggregation of processes,
>>not an aggregation of threads.
> 
> 
> OK; I think I see some of what you're saying here now.  If it isn't 
> urgent, let's defer this until we know what's happening with pnotify.

It's not urgent problem for me.

> I guess I'm most interested in any logic problems I have in the way I used
> pnotify RCU with job, not problems with how Job might have a flaw that has 
> always been there.  Let's address those later.

Yes, I agree. But would you remind that there is a difficulty
to implement an pnotify/PAGG client, if its private-members
are protected by semaphore.

I think implementing a new pnotify's client becomes easier,
if pnotify_subscriber_list would be protected by rwlock.

> If there is no measurable difference, it seems that RCU might not be the
> best answer because we're increasing complexity for no good resaon.

I saw what you posted in LSE-tech.
In my opinion, there is no significant difference between two versions.
fork() and exit() are originally so complex processing which acquires
many locking-objects. Thus, pnotify's cost might be small enough.

Thanks,
-- 
Linux Promotion Center, NEC
KaiGai Kohei <[email protected]>