Merge branch 'for-mingo' of... (f4902829) · Commits · 戴 / test

Documentation/RCU/stallwarn.txt

+15 −1

Original line number	Diff line number	Diff line
		@@ -15,7 +15,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
		21 seconds.

		This configuration parameter may be changed at runtime via the
		/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
		/sys/module/rcupdate/parameters/rcu_cpu_stall_timeout, however
		this parameter is checked only at the beginning of a cycle.
		So if you are 10 seconds into a 40-second stall, setting this
		sysfs parameter to (say) five will shorten the timeout for the
		@@ -152,6 +152,15 @@ no non-lazy callbacks ("." is printed otherwise, as shown above) and
		"D" indicates that dyntick-idle processing is enabled ("." is printed
		otherwise, for example, if disabled via the "nohz=" kernel boot parameter).

		If the relevant grace-period kthread has been unable to run prior to
		the stall warning, the following additional line is printed:

		rcu_preempt kthread starved for 2023 jiffies!

		Starving the grace-period kthreads of CPU time can of course result in
		RCU CPU stall warnings even when all CPUs and tasks have passed through
		the required quiescent states.


		Multiple Warnings From One Stall

		@@ -187,6 +196,11 @@ o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the
		behavior, you might need to replace some of the cond_resched()
		calls with calls to cond_resched_rcu_qs().

		o Anything that prevents RCU's grace-period kthreads from running.
		This can result in the "All QSes seen" console-log message.
		This message will include information on when the kthread last
		ran and how often it should be expected to run.

		o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
		happen to preempt a low-priority task in the middle of an RCU
		read-side critical section. This is especially damaging if

Documentation/RCU/trace.txt

+16 −16

Original line number	Diff line number	Diff line
		@@ -56,14 +56,14 @@ rcuboost:

		The output of "cat rcu/rcu_preempt/rcudata" looks as follows:

		0!c=30455 g=30456 pq=1 qp=1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716
		1!c=30719 g=30720 pq=1 qp=0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982
		2!c=30150 g=30151 pq=1 qp=1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458
		3 c=31249 g=31250 pq=1 qp=0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622
		4!c=29502 g=29503 pq=1 qp=1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521
		5 c=31201 g=31202 pq=1 qp=1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698
		6!c=30253 g=30254 pq=1 qp=1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353
		7 c=31178 g=31178 pq=1 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969
		0!c=30455 g=30456 pq=1/0 qp=1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716
		1!c=30719 g=30720 pq=1/0 qp=0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982
		2!c=30150 g=30151 pq=1/1 qp=1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458
		3 c=31249 g=31250 pq=1/1 qp=0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622
		4!c=29502 g=29503 pq=1/0 qp=1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521
		5 c=31201 g=31202 pq=1/0 qp=1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698
		6!c=30253 g=30254 pq=1/0 qp=1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353
		7 c=31178 g=31178 pq=1/0 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969

		This file has one line per CPU, or eight for this 8-CPU system.
		The fields are as follows:
		@@ -188,14 +188,14 @@ o "ca" is the number of RCU callbacks that have been adopted by this
		Kernels compiled with CONFIG_RCU_BOOST=y display the following from
		/debug/rcu/rcu_preempt/rcudata:

		0!c=12865 g=12866 pq=1 qp=1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871
		1 c=14407 g=14408 pq=1 qp=0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485
		2 c=14407 g=14408 pq=1 qp=0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490
		3 c=14407 g=14408 pq=1 qp=0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290
		4 c=14405 g=14406 pq=1 qp=1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114
		5!c=14168 g=14169 pq=1 qp=0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722
		6 c=14404 g=14405 pq=1 qp=0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811
		7 c=14407 g=14408 pq=1 qp=1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042
		0!c=12865 g=12866 pq=1/0 qp=1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871
		1 c=14407 g=14408 pq=1/0 qp=0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485
		2 c=14407 g=14408 pq=1/0 qp=0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490
		3 c=14407 g=14408 pq=1/0 qp=0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290
		4 c=14405 g=14406 pq=1/0 qp=1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114
		5!c=14168 g=14169 pq=1/0 qp=0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722
		6 c=14404 g=14405 pq=1/0 qp=0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811
		7 c=14407 g=14408 pq=1/0 qp=1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042

		This is similar to the output discussed above, but contains the following
		additional fields:

Documentation/memory-barriers.txt

+45 −1

Original line number	Diff line number	Diff line
		@@ -269,6 +269,50 @@ And there are a number of things that _must_ or _must_not_ be assumed:
		STORE (A + 4) = Y; STORE A = X;
		STORE {A, (A + 4) } = {X, Y};

		And there are anti-guarantees:

		(*) These guarantees do not apply to bitfields, because compilers often
		generate code to modify these using non-atomic read-modify-write
		sequences. Do not attempt to use bitfields to synchronize parallel
		algorithms.

		(*) Even in cases where bitfields are protected by locks, all fields
		in a given bitfield must be protected by one lock. If two fields
		in a given bitfield are protected by different locks, the compiler's
		non-atomic read-modify-write sequences can cause an update to one
		field to corrupt the value of an adjacent field.

		(*) These guarantees apply only to properly aligned and sized scalar
		variables. "Properly sized" currently means variables that are
		the same size as "char", "short", "int" and "long". "Properly
		aligned" means the natural alignment, thus no constraints for
		"char", two-byte alignment for "short", four-byte alignment for
		"int", and either four-byte or eight-byte alignment for "long",
		on 32-bit and 64-bit systems, respectively. Note that these
		guarantees were introduced into the C11 standard, so beware when
		using older pre-C11 compilers (for example, gcc 4.6). The portion
		of the standard containing this guarantee is Section 3.14, which
		defines "memory location" as follows:

		memory location
		either an object of scalar type, or a maximal sequence
		of adjacent bit-fields all having nonzero width

		NOTE 1: Two threads of execution can update and access
		separate memory locations without interfering with
		each other.

		NOTE 2: A bit-field and an adjacent non-bit-field member
		are in separate memory locations. The same applies
		to two bit-fields, if one is declared inside a nested
		structure declaration and the other is not, or if the two
		are separated by a zero-length bit-field declaration,
		or if they are separated by a non-bit-field member
		declaration. It is not safe to concurrently update two
		bit-fields in the same structure if all members declared
		between them are also bit-fields, no matter what the
		sizes of those intervening bit-fields happen to be.


		=========================
		WHAT ARE MEMORY BARRIERS?
		@@ -750,7 +794,7 @@ In summary:
		However, they do -not- guarantee any other sort of ordering:
		Not prior loads against later loads, nor prior stores against
		later anything. If you need these other forms of ordering,
		use smb_rmb(), smp_wmb(), or, in the case of prior stores and
		use smp_rmb(), smp_wmb(), or, in the case of prior stores and
		later loads, smp_mb().

		(*) If both legs of the "if" statement begin with identical stores

arch/arm/kvm/Kconfig

+1 −0

Original line number	Diff line number	Diff line
		@@ -23,6 +23,7 @@ config KVM
		select HAVE_KVM_CPU_RELAX_INTERCEPT
		select KVM_MMIO
		select KVM_ARM_HOST
		select SRCU
		depends on ARM_VIRT_EXT && ARM_LPAE
		---help---
		Support hosting virtualized guest machines. You will also

arch/arm64/kvm/Kconfig

+1 −0

Original line number	Diff line number	Diff line
		@@ -26,6 +26,7 @@ config KVM
		select KVM_ARM_HOST
		select KVM_ARM_VGIC
		select KVM_ARM_TIMER
		select SRCU
		---help---
		Support hosting virtualized guest machines.

Admin message