RE: sync_set_bit() vs set_bit() -- what's the difference?
> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, August 27, 2014 12:39 AM > To: Dexuan Cui > Cc: jer...@goop.org; KY Srinivasan; chr...@sous-sol.org; linux- > ker...@vger.kernel.org > Subject: Re: sync_set_bit() vs set_bit() -- what's the difference? > > >>> On 27.08.14 at 09:30, wrote: > > I'm curious about the difference. :-) > > > > sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while > > set_bit() is used in all other places. What makes hv/xen special? > > I guess this would really want to be used by anything communicating with a > hypervisor or a remote driver: set_bit() gets its LOCK prefix discarded when > the local kernel determines it runs on a single CPU only. Obviously having > knowledge of the CPU count inside a VM does not imply anything about the > number of CPUs available to the host, i.e. stripping LOCK prefixes in that > case > would be unsafe. That is exactly the case for Hyper-V (and Xen). K. Y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sync_set_bit() vs set_bit() -- what's the difference?
On 08/27/2014 09:50 AM, Dexuan Cui wrote: -Original Message- From: Jan Beulich Sent: Wednesday, August 27, 2014 15:39 PM On 27.08.14 at 09:30, wrote: I'm curious about the difference. :-) sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit() is used in all other places. What makes hv/xen special? I guess this would really want to be used by anything communicating with a hypervisor or a remote driver: set_bit() gets its LOCK prefix discarded when the local kernel determines it runs on a single CPU only. Obviously having knowledge of the CPU count inside a VM does not imply anything about the number of CPUs available to the host, i.e. stripping LOCK prefixes in that case would be unsafe. Jan Thank you, Juergen and Jan for your quick answers! I didn't realize LOCK_PREFIX is "" for UP. :-) Even worse: it is patched away dynamically when you disable all but one processor and activated again when a second processor is becoming active. Juergen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: sync_set_bit() vs set_bit() -- what's the difference?
> -Original Message- > From: Jan Beulich > Sent: Wednesday, August 27, 2014 15:39 PM > >>> On 27.08.14 at 09:30, wrote: > > I'm curious about the difference. :-) > > > > sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit() > > is used in all other places. What makes hv/xen special? > > I guess this would really want to be used by anything communicating > with a hypervisor or a remote driver: set_bit() gets its LOCK prefix > discarded when the local kernel determines it runs on a single CPU > only. Obviously having knowledge of the CPU count inside a VM does > not imply anything about the number of CPUs available to the host, > i.e. stripping LOCK prefixes in that case would be unsafe. > > Jan Thank you, Juergen and Jan for your quick answers! I didn't realize LOCK_PREFIX is "" for UP. :-) Thanks, -- Dexuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sync_set_bit() vs set_bit() -- what's the difference?
>>> On 27.08.14 at 09:30, wrote: > I'm curious about the difference. :-) > > sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit() > is used in all other places. What makes hv/xen special? I guess this would really want to be used by anything communicating with a hypervisor or a remote driver: set_bit() gets its LOCK prefix discarded when the local kernel determines it runs on a single CPU only. Obviously having knowledge of the CPU count inside a VM does not imply anything about the number of CPUs available to the host, i.e. stripping LOCK prefixes in that case would be unsafe. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sync_set_bit() vs set_bit() -- what's the difference?
On 08/27/2014 09:30 AM, Dexuan Cui wrote: I'm curious about the difference. :-) sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit() is used in all other places. What makes hv/xen special? In set_bit() the "lock" prefix will be dropped if only one processor is present. sync_set_bit() is always attributed with "lock". xen and hv might require "lock" semantics even if the current OS is running on only one processor, as syncing with other processors running other OS's might be necessary. Juergen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
