Re: uvm_pmemrange.c questions
On Tue, Mar 01, 2011 at 05:37:49PM -0600, Amit Kulkarni wrote:
> I found 2 possible null pointers by clang static analyzer and I have
> attached it to email later. I was also reading the code in this file
> and I found out that
>
> 1) most of the time in uvm_pmr_getpages(), a newly inserted printf at
> line 792 is never reached. I put that printf just to check and verify
> a clang warning that search[] is uninitialized. Almost all page
> allocations during boot and seen in dmesg are happening in either on
> line 786 or line 789 in
>
> if (maxseg == 1 || count == 1)
> and
> else if (maxseg >= count && (flags & UVM_PLA_TRYCONTIG) == 0) {
>
> So is that else {} block not being reached and is redundant?
It's not redundant.
Consider the case where maxseg > 1, count > 1 and maxseg < count
(for instance maxseg = 2, count = 3).
This rare case will reach the 3rd block.
It being reached rarely is because:
- most allocations are for a single page (uvm_pagealloc)
- most many-page allocations are allocated by a dma controller which
will have maxseg=1 or maxseg=count only.
> It looks
> like it from the code, as it is only called from uvm_page.c and
> uvm_pglist.c and the if () condition. Is the allocator then spending a
> lot of time in the search[2] case? Or am I crazy to think that
> something's off in that area?
The search[2] case is more pessimistic and slower than the search[1]
case, which in turn is more pessimistic and slower than the search[0]
case.
However, the slower cases are optimized out in the different
if-statements.
> 2) another question. Most allocations are either 1 or a power of two.
> But there are a few allocations of 3 pages, specifically most
> allocations are either 1 page, 2 page, some 16's, some 32's, one
> single 128. I printed this info by checking for value of search[try]
> at label rescan: on line 901 in uvm_pmemrange.c
>
> Would this cause fragmentation or misalignment and ultimately a
> problem?
Fragmentation is filled out aggressively. Suppose the 3-page allocation
came from a range that contained 5 pages, then the 2 remaining pages
(which may or may not be contiguous) will be quickly handed out to an
allocation that will be fine with them.
Or more formally:
- each free space consists of a contig range of pages, where no 2 free
spaces will exist that "connect",
- the free spaces are kept in a set, sorted on their size,
- every allocation will be fulfilled using the first elements that do
not violate the allocation constraints.
However, you can check the current level of fragmentation by dropping in
ddb:
call uvm_pmr_print()
-- output on my laptop --
Ranges, use queue:
* [0x1000-0x10] use=1 nsegs=2514 maxsegsz[0]=0x6a7d0 maxsegsz[1]=0x0
free=0xde66e
* [0x0-0x1000] use=2 nsegs=5 maxsegsz[0]=0x45c maxsegsz[1]=0x0
free=0xa66
#ranges = 2
--
The nsegs value shows how many segments are available, while the
maxsegsz describes the size of the largest segment, i.e. the largest
contig allocation that is possible.
In this case, 0x6a7d0 pages (1.7GB) contig memory is available.
(Hex numbers are page counts, so need to be multiplied by pagesize.)
> There were exactly eight 3 page allocations after bios got
> handed control to /bsd immediately after the lines
>
> real mem = 8587771904 (8189MB)
> avail mem = 8345174016 (7958MB)
>
> and a single 3 page allocation after mtrr:Pentium Pro MTRR support. I
> get a usb_allocmem() issue right after this line on a NVIDIA USB EHCI
> controller on this Sun Ultra 40 with NVIDIA everything. I am attaching
> a dmesg also. I have to keep the ehci commented in GENERIC to get it
> to boot or disable ehci in UKC everytime.
>
> Would this single odd 3 page alloc cause a problem? Or am I crazy to
> think it should?
Shouldn't be a problem.
> Thanks for your time,
> amit
>
> clang reports for the null pointers
>
> https://filestogeaux.lsu.edu/public/download.php?FILE=akulka1/20861LJ6oU4
> https://filestogeaux.lsu.edu/public/download.php?FILE=akulka1/32877HWMeIq
> https://filestogeaux.lsu.edu/public/download.php?FILE=akulka1/12907BUBXhj
>
>
> Index: uvm_pmemrange.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_pmemrange.c,v
> retrieving revision 1.18
> diff -u -i uvm_pmemrange.c
> --- uvm_pmemrange.c 28 Aug 2010 22:27:47 - 1.18
> +++ uvm_pmemrange.c 1 Mar 2011 22:28:46 -
> @@ -634,7 +634,7 @@
>* uvm_page_init() may not have initialized its array sorted by
>* page number.
>*/
> - for (iter = start; iter != end; iter = iter_end) {
> + for (iter = start; iter != NULL && iter != end; iter = iter_end) {
end is guaranteed to be either NULL or between iter and end of the list.
Therefor this is not a null pointer error.
> iter_end = TAILQ_NEXT(iter, pageq);
> TAILQ_REMOVE(pgl, iter, pageq);
> }
> @@ -1628,7 +1628,7 @@
>* Ack, no hits. Walk the address tree until to find something usable.
>*/
>
spamd.8 patch
I was just setting up spamd in blacklist mode on the latest snap and discovered the man page is missing the "in" between "pass on". Diff attached. Index: spamd.8 === RCS file: /cvs/src/libexec/spamd/spamd.8,v retrieving revision 1.117 diff -u -p -r1.117 spamd.8 --- spamd.8 17 Sep 2009 06:37:54 - 1.117 +++ spamd.8 18 Mar 2011 23:09:43 - @@ -477,7 +477,7 @@ Any other addresses are passed to the real MTA. .Bd -literal -offset 4n table \*(Ltspamd\*(Gt persist -pass on egress proto tcp from \*(Ltspamd\*(Gt to any \e +pass in on egress proto tcp from \*(Ltspamd\*(Gt to any \e port smtp rdr-to 127.0.0.1 port spamd .Ed .Pp
PATCH: Fix boolean value for ACPI logical comparisons
This patch changes the values of boolean comparisons from 0:1 to 0:-1 (from ACPI Spec) in order to fix an AML issue on some Asus machines. Please test on other machines as well to verify that hardware sensors/acpi/boot work properly. Index: dsdt.c === RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v retrieving revision 1.181 diff -u -p -b -r1.181 dsdt.c --- dsdt.c 2 Jan 2011 04:56:57 - 1.181 +++ dsdt.c 18 Mar 2011 21:55:16 - @@ -1167,31 +1167,31 @@ aml_evalexpr(int64_t lhs, int64_t rhs, i /* Logical/Comparison */ case AMLOP_LAND: - res = (lhs && rhs); + res = -(lhs && rhs); break; case AMLOP_LOR: - res = (lhs || rhs); + res = -(lhs || rhs); break; case AMLOP_LNOT: - res = (!lhs); + res = -(!lhs); break; case AMLOP_LNOTEQUAL: - res = (lhs != rhs); + res = -(lhs != rhs); break; case AMLOP_LLESSEQUAL: - res = (lhs <= rhs); + res = -(lhs <= rhs); break; case AMLOP_LGREATEREQUAL: - res = (lhs >= rhs); + res = -(lhs >= rhs); break; case AMLOP_LEQUAL: - res = (lhs == rhs); + res = -(lhs == rhs); break; case AMLOP_LGREATER: - res = (lhs > rhs); + res = -(lhs > rhs); break; case AMLOP_LLESS: - res = (lhs < rhs); + res = -(lhs < rhs); break; }
El Metodo exacto para Conseguir Resultados en Ventas - La Venta Consultiva - 30 de Marzo - MERIDA
CURSO TALLER El Metodo exacto para Conseguir Resultados en Ventas - La Venta Consultiva Experto instructor: Lic. Carlos Gerardo Melgar Juarez ) Duracion: (1 dia) 8 hrs. Inversion: $3,150 pesos mas IVA Objetivo: Al finalizar el curso el participante lograra convertirse en un vendedor de ALTO RENDIMIENTO, mediante el aprendizaje de un mitodo CIENTIFICO Y PRACTICO que colabore a optimizar resultados en el cierre de negocios y sobre todo que aumente su rentabilidad. Alcance: En su labor diaria el vendedor aplicara un mitodo probado y eficaz para convertirse en un verdadero CONSULTOR DE VENTAS. MERIDA Sede: Hotel Mision Merida Panamericana - Calle 59 # 455 Centro Historico, Merida, Yuc. 30 de Marzo Solicite Temario de Click Aqui Cursos de Marketing y Ventas [IMAGE] Curso Taller La Gerencia de Ventas Efectiva, Incrementando Productividad Comercial Mexico / Guadalajara / Monterrey [IMAGE] Curso Taller El metodo exacto para conseguir resultados en ventas - La Venta Consultiva Mexico / Guadalajara / Monterrey [IMAGE] Curso Taller Liderazgo y Coaching Gerencial en Ventas Mexico / Guadalajara / Monterrey Consulte la Programacion por Area: Manufactura y Produccion | Credito y Cobranza | Recursos Humanos | Adquisiciones y Obras Publicas | Entrenamiento Ejecutivo | Seguridad e Higiene | Negociacion y Compras | Alimentos y Bebidas | Economia y Finanzas | Asistentes Ejecutivas | Marketing y Ventas | Si necesita mayor informacion,comuniquese un Asesor lo atendera de inmediato. SIMCA CAPACITACION Entrenamiento Especializado E-MAIL: simca_capacitac...@hotmail.com Messenger: simca_capacitac...@hotmail.com Lada sin costo: 01 800 543 32 30 Servicios de Informacion Mexicana Capacitando America Diseqamos el curso a la medida de sus necesidades..!Impartimos CURSOS de forma PRIVADA en su empresa, envienos un correo especificando el numero de participantes, el lugar donde se impartira, su nombre, cargo, empresa y telefono.SOLICITE COTIZACION de Click Aqui Si usted no desea que le enviemos mas invitaciones, de Click Aqui, gracias.
permit daily(8) to use DUID in /etc/fstab for ROOTBACKUP
Hi all,
This diff enables daily(8) to use DUID instead of pathname in
/etc/fstab for backing up root filesystem.
I'm not a shell expert... comments are welcome.
Index: daily
===
RCS file: /cvs/src/etc/daily,v
retrieving revision 1.68
diff -u -r1.68 daily
--- daily 22 Sep 2010 13:01:10 - 1.68
+++ daily 18 Mar 2011 15:15:57 -
@@ -97,11 +97,22 @@
rootbak=`awk '$2 == "/altroot" && $1 ~ /^\/dev\// && $3 == "ffs" && \
$4 ~ /xx/ \
{ print substr($1, 6) }' < /etc/fstab`
- if [ -z "$rootbak" ]; then
- echo "No xx ffs /altroot device found in the fstab(5)."
- break
+ if [ ! -z $rootbak ]; then
+ bakdisk=${rootbak%[a-p]}
+ else
+ duid=`awk '$2 == "/altroot" && $1 ~ /^.*\..*/ && \
+ $3 == "ffs" && $4 ~ /xx/ \
+ { print substr($1, 1, 18) }' < /etc/fstab`
+ if [ -z "$duid" ]; then
+ echo "No xx ffs /altroot device found in the fstab(5)."
+ break
+ fi
+ duiddisk=`echo $duid | awk '{ print substr($1, 1, 16) }'`
+ bakdisk=`sysctl -n hw.disknames | \
+ sed -e 's/.*[,=]\(.*\):'$duiddisk'.*/\1/'`
+ rootbak=`echo $duid | \
+ awk '{ print "'$bakdisk'"substr($1, 18, 1) }'`
fi
- bakdisk=${rootbak%[a-p]}
sysctl -n hw.disknames | grep -Fqw $bakdisk || break
bakpart=${rootbak#$bakdisk}
baksize=`disklabel $bakdisk 2>/dev/null | \
--
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."
