Re: [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Gautham R Shenoy
Date: Sunday, October 21, 2007 - 9:51 pm

> > 

Hi Nathan, 
I totally see your point and agree with it. 

However, though the new implementation appears to have
a read-write-semaphore behaviour it differs in 
following aspects:

a) This implementation allows natural recursion of reads, just
as in the case of preempt_count. 
This is not possible in case of a normal read-write
lock because if you have something like the following in
a timeline, 
R1 -- > R2--> W3 --> R1, where 
Ri is a read by a thread i and
Wi is a write by a thread i, 
then thread1 will deadlock as it will be blocked behind W3, 
holding the semaphore.

b) Regular Reader Writer semaphores are fair. As in if a new reader
arrives when a writer is already present, the new reader waits until
the writer in front of it finishes. But, in the new implementation, 
the new reader will proceed as long as the refcount is non-zero, and the
writer will get to run only when the number of readers = 0. However, the
readers which arrive when the writer is executing, will block until the
writer is done.

Because of these properties, the implementation is more similar to the
refcounting, except that it allows the new bunch of readers to
sleep during an ongoing write.

Like you pointed out, since the code of pseries_add_processor and 
other places where the cpu_present_map is being changed during the
runtime requires write protection, how if the 
cpu_hotplug_begin/cpu_hotplug_end support is made
available outside cpu.c and appropriately named ?

Personally I would propose the following names to reflect the behaviour, 
but if the community is okay with the word "lock" in the API's I don't
have any problems renaming them to what you've suggested.

/* 
 * Api's which ensure that the cpu_present_map and the cpu_online_map
 * do not change while operating in a critical section.
 */
 
 get_cpu_maps();
 put_cpu_maps();

/* 
 * Api's to serialize the updates to the cpu_present_map/cpu_online_map.
 */

 cpu_map_update_begin();
 cpu_map_update_done();

Thanks and Regards
gautham.
-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit., Gautham R Shenoy, (Tue Oct 16, 3:33 am)
[RFC PATCH 1/4] Refcount Based Cpu-Hotplug Implementation, Gautham R Shenoy, (Tue Oct 16, 3:34 am)
[RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus, Gautham R Shenoy, (Tue Oct 16, 3:35 am)
[RFC PATCH 4/4] Remove CPU_DEAD/CPU_UP_CANCELLED handling ..., Gautham R Shenoy, (Tue Oct 16, 3:37 am)
Re: [RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit., Linus Torvalds, (Tue Oct 16, 10:20 am)
Re: [RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit., Dipankar Sarma, (Tue Oct 16, 7:11 pm)
Re: [RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit., Linus Torvalds, (Tue Oct 16, 7:23 pm)
Re: [RFC PATCH 0/4] Refcount Based Cpu-Hotplug Revisit., Gautham R Shenoy, (Tue Oct 16, 9:17 pm)
Re: [RFC PATCH 1/4] Refcount Based Cpu-Hotplug Implementation, Gautham R Shenoy, (Tue Oct 16, 10:37 pm)
Re: [RFC PATCH 1/4] Refcount Based Cpu-Hotplug Implementation, Gautham R Shenoy, (Wed Oct 17, 4:50 am)
Re: [RFC PATCH 1/4] Refcount Based Cpu-Hotplug Implementation, Gautham R Shenoy, (Wed Oct 17, 11:29 pm)
Re: [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus, Gautham R Shenoy, (Thu Oct 18, 12:57 am)
Re: [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus, Gautham R Shenoy, (Thu Oct 18, 10:04 pm)
Re: [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus, Gautham R Shenoy, (Sun Oct 21, 9:51 pm)