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 <kaigai@xxxxxxxxxxxxx>
|