#
cfdfd32d |
| 26-Jun-2011 |
Attilio Rao <attilio@FreeBSD.org> |
MFC
|
#
1aac6ac9 |
| 25-Jun-2011 |
Andriy Gapon <avg@FreeBSD.org> |
generic_stop_cpus: pull timeout logic from under DIAGNOSTIC
... and also increase the timeout. It's better to try to proceed somehow despite stuck CPUs than to hang indefinitely. Especially so duri
generic_stop_cpus: pull timeout logic from under DIAGNOSTIC
... and also increase the timeout. It's better to try to proceed somehow despite stuck CPUs than to hang indefinitely. Especially so during shutdown and when entering kdb or panic.
Timeout value is still an aribitrary value. Timeout diagnostic is just a printf; the work on something more debuggable is planned by attilio. Need to be careful here as stop_cpus_hard is called very early while enetering kdb and soon(-ish) it may become called very early when entering panic.
Reviewed by: attilio MFC after: 2 months
show more ...
|
#
a38f1f26 |
| 13-Jun-2011 |
Attilio Rao <attilio@FreeBSD.org> |
Remove pc_cpumask and pc_other_cpus usage from MI code.
Tested by: pluknet
|
#
033e1e35 |
| 07-Jun-2011 |
Attilio Rao <attilio@FreeBSD.org> |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. An
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. Anyway, as long as several structures in the kernel are statically allocated and sized as MAXCPU, it is suggested to keep it as low as possible for the time being.
Technical notes on this commit itself: - More functions to handle with cpuset_t objects are introduced. The most notable are cpusetobj_ffs() (which calculates a ffs(3) for a cpuset_t object), cpusetobj_strprint() (which prepares a string representing a cpuset_t object) and cpusetobj_strscan() (which creates a valid cpuset_t starting from a string representation). - pc_cpumask and pc_other_cpus are target to be removed soon. With the moving from cpumask_t to cpuset_t they are now inefficient and not really useful. Anyway, for the time being, please note that access to pcpu datas is protected by sched_pin() in order to avoid migrating the CPU while reading more than one (possible) word - Please note that size of cpuset_t objects may differ between kernel and userland. While this is not directly related to the patch itself, it is good to understand that concept and possibly use the patch as a reference on how to deal with cpuset_t objects in userland, when accessing kernland members. - KTR_CPUMASK is changed and now is represented through a string, to be set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but private testing has been done until to MAXCPU=128 on a real 8x8x2(htt) machine (amd64).
Please note that the FreeBSD version is not yet bumped because of the upcoming pcpu changes. However, note that this patch is not targeted for MFC.
People to thank for the time spent on this patch: - sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested several revision of the patches and really helped in improving stability of this work. - marius fixed several bugs in the sparc64 implementation and reviewed patches related to ktr. - jeff and jhb discussed the basic approach followed. - kib and marcel made targeted review on some specific part of the patch. - marius, art, nwhitehorn and andreast reviewed MD specific part of the patch. - marius, andreast, gonzo, nwhitehorn and jceel tested MD specific implementations of the patch. - Other people have made contributions on other patches that have been already committed and have been listed separately.
Companies that should be mentioned for having participated at several degrees: - Yahoo! for having offered the machines used for testing on big count of CPUs. - The FreeBSD Foundation for having sponsored my devsummit attendance, which has been instrumental. - Sandvine for having offered offices and infrastructure during development.
(I really hope I didn't forget anyone, if it happened I apologize in advance).
show more ...
|
#
7fcdc9a2 |
| 26-May-2011 |
Attilio Rao <attilio@FreeBSD.org> |
MFC
|
#
5b41f90f |
| 24-May-2011 |
John Baldwin <jhb@FreeBSD.org> |
Silly spelling typos.
Submitted by: "b. f."
|
#
87c3644c |
| 24-May-2011 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r222256
|
#
47ad691f |
| 24-May-2011 |
John Baldwin <jhb@FreeBSD.org> |
Fix an issue with critical sections and SMP rendezvous handlers. Specifically, a critical_exit() call that drops the nesting level to zero has a brief window where the pending preemption flag is set
Fix an issue with critical sections and SMP rendezvous handlers. Specifically, a critical_exit() call that drops the nesting level to zero has a brief window where the pending preemption flag is set and the nesting level is set to zero. This is done purposefully to avoid races where a preemption scheduled by an interrupt could be lost otherwise (see revision 144777). However, this does mean that if an interrupt fires during this window and enters and exits a critical section, it may preempt from the interrupt context. This is generally fine as the interrupt code is careful to arrange critical sections so that they are not exited until it is safe to preempt (e.g. interrupts EOI'd and masked if necessary).
However, the SMP rendezvous IPI handler does not quite follow this rule, and in general a rendezvous can never be preempted. Rendezvous handlers are also not permitted to schedule threads to execute, so they will not typically trigger preemptions. SMP rendezvous handlers may use spinlocks (carefully) such as the rm_cleanIPI() handler used in rmlocks, but using a spinlock also enters and exits a critical section. If the interrupted top-half code is in the brief window of critical_exit() where the nesting level is zero but a preemption is pending, then releasing the spinlock can trigger a preemption. Because we know that SMP rendezvous handlers can never schedule a thread, we know that a critical_exit() in an SMP rendezvous handler will only preempt in this edge case. We also know that the top-half thread will happily handle the deferred preemption once the SMP rendezvous has completed, so the preemption will not be lost.
This makes it safe to employ a workaround where we use a nested critical section in the SMP rendezvous code itself around rendezvous action routines to prevent any preemptions during an SMP rendezvous. The workaround intentionally avoids checking for a deferred preemption when leaving the critical section on the assumption that if there is a pending preemption it will be handled by the interrupted top-half code.
Submitted by: mlaier (variation specific to rm_cleanIPI()) Obtained from: Isilon MFC after: 1 week
show more ...
|
#
a8586bee |
| 18-May-2011 |
Attilio Rao <attilio@FreeBSD.org> |
Fix mismerge.
Reported by: pluknet
|
#
fea3a3fa |
| 18-May-2011 |
Attilio Rao <attilio@FreeBSD.org> |
MFC
|
#
f83e8b25 |
| 17-May-2011 |
John Baldwin <jhb@FreeBSD.org> |
Fix a race in the SMP rendezvous code. Specifically, the write by the last CPU to to finish the rendezvous action may become visible to different CPUs at different times. As a result, the CPU that
Fix a race in the SMP rendezvous code. Specifically, the write by the last CPU to to finish the rendezvous action may become visible to different CPUs at different times. As a result, the CPU that initiated the rendezvous may exit the rendezvous and drop the lock allowing another rendezvous to be initiated on the same CPU or a different CPU. In that case the exit sentinel may be cleared before all CPUs have noticed causing those CPUs to hang forever.
Workaround this by using a generation count to notice when this race occurs and to exit the rendezvous in that case.
The problem was independently diagnosted by mlaier@ and avg@ as well.
Submitted by: neel Reviewed by: avg, mlaier Obtained from: NetApp MFC after: 1 week
show more ...
|
#
d59dd76c |
| 17-May-2011 |
Attilio Rao <attilio@FreeBSD.org> |
Merge r221278 from largeSMP project: idle_cpus_mask is just used in sched_4bsd, thus make it private for it.
Tested by: several
|
#
71a19bdc |
| 05-May-2011 |
Attilio Rao <attilio@FreeBSD.org> |
Commit the support for removing cpumask_t and replacing it directly with cpuset_t objects. That is going to offer the underlying support for a simple bump of MAXCPU and then support for number of cpu
Commit the support for removing cpumask_t and replacing it directly with cpuset_t objects. That is going to offer the underlying support for a simple bump of MAXCPU and then support for number of cpus > 32 (as it is today).
Right now, cpumask_t is an int, 32 bits on all our supported architecture. cpumask_t on the other side is implemented as an array of longs, and easilly extendible by definition.
The architectures touched by this commit are the following: - amd64 - i386 - pc98 - arm - ia64 - XEN
while the others are still missing. Userland is believed to be fully converted with the changes contained here.
Some technical notes: - This commit may be considered an ABI nop for all the architectures different from amd64 and ia64 (and sparc64 in the future) - per-cpu members, which are now converted to cpuset_t, needs to be accessed avoiding migration, because the size of cpuset_t should be considered unknown - size of cpuset_t objects is different from kernel and userland (this is primirally done in order to leave some more space in userland to cope with KBI extensions). If you need to access kernel cpuset_t from the userland please refer to example in this patch on how to do that correctly (kgdb may be a good source, for example). - Support for other architectures is going to be added soon - Only MAXCPU for amd64 is bumped now
The patch has been tested by sbruno and Nicholas Esborn on opteron 4 x 12 pack CPUs. More testing on big SMP is expected to came soon. pluknet tested the patch with his 8-ways on both amd64 and i386.
Tested by: pluknet, sbruno, gianni, Nicholas Esborn Reviewed by: jeff, jhb, sbruno
show more ...
|
#
3121f534 |
| 01-May-2011 |
Attilio Rao <attilio@FreeBSD.org> |
idle_cpus_mask is just used in the SMP case and within sched_4BSD. Declare appropriately.
|
#
9b4fcf85 |
| 18-Feb-2011 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@218816
|
Revision tags: release/7.4.0_cvs, release/8.2.0_cvs, release/7.4.0, release/8.2.0 |
|
#
37142d9e |
| 11-Feb-2011 |
Juli Mallett <jmallett@FreeBSD.org> |
With smp_topo_none, set cg_mask to all_cpus rather than setting the mp_ncpus low bits.
Submitted by: Bhanu Prakash Reviewed by: jeffr
|
#
fbbb13f9 |
| 12-Jan-2011 |
Matthew D Fleming <mdf@FreeBSD.org> |
sysctl(9) cleanup checkpoint: amd64 GENERIC builds cleanly.
Commit the kernel changes.
|
#
6f3544cd |
| 26-Oct-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@214309
|
#
9ddb6637 |
| 12-Oct-2010 |
Andriy Gapon <avg@FreeBSD.org> |
generic_stop_cpus: prevent parallel execution
This is based on the same approach as used in panic(). In theory parallel execution of generic_stop_cpus() could lead to two CPUs stopping each other a
generic_stop_cpus: prevent parallel execution
This is based on the same approach as used in panic(). In theory parallel execution of generic_stop_cpus() could lead to two CPUs stopping each other and everyone else, and thus a total system halt. Also, in theory, we should have some smarter locking here, because two (or more CPUs) could be stopping unrelated sets of CPUs. But in practice, it seems, this function is only used to stop "all other" CPUs.
Additionally, I took this opportunity to make amd64-specific suspend_cpus() function use generic_stop_cpus() instead of rolling out essentially duplicate code.
This code is based on code by Sandvine Incorporated.
Suggested by: mdf Reviewed by: jhb, jkim (earlier version) MFC after: 2 weeks
show more ...
|
#
b17f9ad2 |
| 16-Aug-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@211344
|
#
2d8b420b |
| 09-Aug-2010 |
Attilio Rao <attilio@FreeBSD.org> |
The r208165 fixed a bug related to unsigned integer overflowing for the number of CPUs detection. However, that was not mention at all, the problem was not reported, the patch has not been MFCed and
The r208165 fixed a bug related to unsigned integer overflowing for the number of CPUs detection. However, that was not mention at all, the problem was not reported, the patch has not been MFCed and the fix is mostly improper.
Fix the original overflow (caused when 32 CPUs must be detected) by just using a different mathematical computation (it also makes more explicit the size of operands involved, which is good in the moment waiting for a more complete support for a large number of CPUs).
PR: kern/148698 Submitted by: Joe Landers <jlanders at vmware dot com> Tested by: gianni MFC after: 10 days
show more ...
|
#
d9d8d144 |
| 06-Aug-2010 |
John Baldwin <jhb@FreeBSD.org> |
Add a new ipi_cpu() function to the MI IPI API that can be used to send an IPI to a specific CPU by its cpuid. Replace calls to ipi_selected() that constructed a mask for a single CPU with calls to
Add a new ipi_cpu() function to the MI IPI API that can be used to send an IPI to a specific CPU by its cpuid. Replace calls to ipi_selected() that constructed a mask for a single CPU with calls to ipi_cpu() instead. This will matter more in the future when we transition from cpumask_t to cpuset_t for CPU masks in which case building a CPU mask is more expensive.
Submitted by: peter, sbruno Reviewed by: rookie Obtained from: Yahoo! (x86) MFC after: 1 month
show more ...
|
Revision tags: release/8.1.0_cvs, release/8.1.0 |
|
#
95bf6530 |
| 12-Jun-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@209086
|
#
3aa6d94e |
| 11-Jun-2010 |
John Baldwin <jhb@FreeBSD.org> |
Update several places that iterate over CPUs to use CPU_FOREACH().
|
#
7708106a |
| 26-May-2010 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@208557
|