src/lib/libmemstat, branch releng/9.3FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=releng%2F9.32012-10-30T17:05:12ZMFC r242152:2012-10-30T17:05:12ZMatthew D Flemingmdf@FreeBSD.org2012-10-30T17:05:12Zurn:sha1:bc4a4251bb474a97c8fef1e77fa66115adf24350
Const-ify the zone name argument to uma_zcreate(9).
MFC r232157, r232158:2012-04-26T20:11:57ZGlen Barbergjb@FreeBSD.org2012-04-26T20:11:57Zurn:sha1:2082345d1e9c8ea29ecb1f51e635def437fefbe0
r232157:
Fix various typos in manual pages.
Submitted by: amdmi3
PR: 165431
r232158:
Whitespace cleanup:
o Wrap sentences on to new lines
o Cleanup trailing whitespace
Cosmetic cleanup: remove #define LIBMEMSTAT used to prevent a nested2011-09-02T14:10:42ZSergey Kandaurovpluknet@FreeBSD.org2011-09-02T14:10:42Zurn:sha1:cfc9e655bacc58c2098f47f52302884beb1453c1
include of opt_vmpage.h from vm/vm_page.h. opt_vmpage.h was retired
before 7.0 together with options PQ_NOOPT.
Approved by: re (kib)
MFC after: 3 days
Get rid of MAXCPU knowledge used for internal needs only. Switch to2011-08-01T09:43:35ZSergey Kandaurovpluknet@FreeBSD.org2011-08-01T09:43:35Zurn:sha1:1882360b9b0fbd7f4ddcd6fb35674ec309b2a738
dynamic memory allocation to hold per-CPU memory types data (sized to
mp_maxid for UMA, and to mp_maxcpus for malloc to match the kernel).
That fixes libmemstat with arbitrary large MAXCPU values and therefore
eliminates MEMSTAT_ERROR_TOOMANYCPUS error type.
Reviewed by: jhb
Approved by: re (kib)
Revert r222363, as bde@ pointed out the initial solution was far more2011-05-31T20:59:53ZAttilio Raoattilio@FreeBSD.org2011-05-31T20:59:53Zurn:sha1:1de471dfee9267dde6b33dd262faefffb2b71bc9
correct.
Style fix: cast to size_t rather than u_long when comparing to sizeof()2011-05-27T16:01:51ZAttilio Raoattilio@FreeBSD.org2011-05-27T16:01:51Zurn:sha1:d361ed4b1ca199522f067ecf7b9fd66d10642d1e
rets.
Requested by: kib
Sync with -CURRENT2011-05-10T18:01:53ZAttilio Raoattilio@FreeBSD.org2011-05-10T18:01:53Zurn:sha1:d40d5f64a2f17d7f00658f6f04c8b65b746ee3faFix a mismerge.2011-05-08T14:45:53ZAttilio Raoattilio@FreeBSD.org2011-05-08T14:45:53Zurn:sha1:be720a4061f9da8e1844da27b17fbb50322a293bRevert MAXCPU introduction. In userland it is always 1.2011-05-08T14:29:25ZAttilio Raoattilio@FreeBSD.org2011-05-08T14:29:25Zurn:sha1:34e4a6f408ae92e30d943f1083807e2932497371
Noted by: marcel
Commit the support for removing cpumask_t and replacing it directly with2011-05-05T14:39:14ZAttilio Raoattilio@FreeBSD.org2011-05-05T14:39:14Zurn:sha1:71a19bdc640eb9d54e7db3d1d135753888f3469c
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