#
1b54fbe6 |
| 09-Jan-2013 |
Neel Natu <neel@FreeBSD.org> |
IFC @ r245178
|
#
fdf78e78 |
| 08-Jan-2013 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
Switch default cache type for ARMv6/ARMv7 from write-through to writeback-writeallocate
|
#
46b1c55d |
| 04-Jan-2013 |
Neel Natu <neel@FreeBSD.org> |
IFC @ r244983.
|
#
b9a3b766 |
| 20-Dec-2012 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
Fix misleading comment
|
#
65d79ed7 |
| 19-Dec-2012 |
Olivier Houchard <cognet@FreeBSD.org> |
Properly implement pmap_[get|set]_memattr
Submitted by: Ian Lepore <freebsd@damnhippie.dyndns.org>
|
Revision tags: release/9.1.0 |
|
#
e477abf7 |
| 27-Nov-2012 |
Alexander Motin <mav@FreeBSD.org> |
MFC @ r241285
|
#
a10c6f55 |
| 11-Nov-2012 |
Neel Natu <neel@FreeBSD.org> |
IFC @ r242684
|
#
23090366 |
| 04-Nov-2012 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Sync from head
|
#
a1685193 |
| 30-Sep-2012 |
Alan Cox <alc@FreeBSD.org> |
Eliminate an unused declaration.
|
#
703205f3 |
| 27-Sep-2012 |
Alan Cox <alc@FreeBSD.org> |
Implementing pmap_kextract(va) as pmap_extract(kernel_pmap, va) is problematic because some callers to pmap_kextract() expect its implementation to be lock-less. In particular, uma_dbg_alloc() impli
Implementing pmap_kextract(va) as pmap_extract(kernel_pmap, va) is problematic because some callers to pmap_kextract() expect its implementation to be lock-less. In particular, uma_dbg_alloc() implicitly requires this. Otherwise, lock-order reversals occur between pmap locks and UMA zone locks. So, this change introduces a lock-less implementation of pmap_kextract().
Disable recursion on the pvh global lock in the new armv6 pmap. While recursion on this locks occurs in the old arm pmap, it thankfully doesn't occur in the armv6 pmap.
Tested by: jmg
show more ...
|
#
b95d8bec |
| 07-Sep-2012 |
Alan Cox <alc@FreeBSD.org> |
Eliminate an unused macro.
|
#
24bf3585 |
| 04-Sep-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r240095.
|
#
cf1a573f |
| 15-Aug-2012 |
Oleksandr Tymoshenko <gonzo@FreeBSD.org> |
Merging projects/armv6, part 1
Cummulative patch of changes that are not vendor-specific: - ARMv6 and ARMv7 architecture support - ARM SMP support - VFP/Neon support - ARM Generic Interrupt Cont
Merging projects/armv6, part 1
Cummulative patch of changes that are not vendor-specific: - ARMv6 and ARMv7 architecture support - ARM SMP support - VFP/Neon support - ARM Generic Interrupt Controller driver - Simplification of startup code for all platforms
show more ...
|
#
de720122 |
| 15-Jul-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r236710 through r238467.
|
#
6cf87ec8 |
| 13-Jul-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @238412.
|
#
b652778e |
| 11-Jul-2012 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r238370
|
#
6031c68d |
| 16-Jun-2012 |
Alan Cox <alc@FreeBSD.org> |
The page flag PGA_WRITEABLE is set and cleared exclusively by the pmap layer, but it is read directly by the MI VM layer. This change introduces pmap_page_is_write_mapped() in order to completely en
The page flag PGA_WRITEABLE is set and cleared exclusively by the pmap layer, but it is read directly by the MI VM layer. This change introduces pmap_page_is_write_mapped() in order to completely encapsulate all direct access to PGA_WRITEABLE in the pmap layer.
Aesthetics aside, I am making this change because amd64 will likely begin using an alternative method to track write mappings, and having pmap_page_is_write_mapped() in place allows me to make such a change without further modification to the MI VM layer.
As an added bonus, tidy up some nearby comments concerning page flags.
Reviewed by: kib MFC after: 6 weeks
show more ...
|
#
ee5cac8a |
| 13-Jun-2012 |
Warner Losh <imp@FreeBSD.org> |
trim trailing whitespace
|
Revision tags: release/8.3.0_cvs, release/8.3.0 |
|
#
8fa0b743 |
| 23-Jan-2012 |
Xin LI <delphij@FreeBSD.org> |
IFC @230489 (pending review).
|
#
80dbff4e |
| 04-Jan-2012 |
Sean Bruno <sbruno@FreeBSD.org> |
IFC to head to catch up the bhyve branch
Approved by: grehan@
|
Revision tags: release/9.0.0 |
|
#
68f8dc29 |
| 15-Dec-2011 |
Rafal Jaworowski <raj@FreeBSD.org> |
ARM pmap fixes:
- Write Buffers have to be drained after write to Page Table even if caches are in write-through mode.
- Make sure to sync PTE in pmap_zero_page_generic().
Submitted by: Michal M
ARM pmap fixes:
- Write Buffers have to be drained after write to Page Table even if caches are in write-through mode.
- Make sure to sync PTE in pmap_zero_page_generic().
Submitted by: Michal Mazur Reviewed by: cognet Obtained from: Semihalf MFC after: 1 month
show more ...
|
#
a5615c90 |
| 28-Jun-2011 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r222830
|
#
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 ...
|
#
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 ...
|
#
9b4fcf85 |
| 18-Feb-2011 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Merge svn+ssh://svn.freebsd.org/base/head@218816
|