>Yes, p_args caches the arguments, but not always. Right now, kernel
>does not cache arguments if the string is longer than 256 bytes. Look
>for ps_arg_cache_limit in kern_exec.c.
>
>setproctitle() always informs the kernel with sysctl and sets the
>pointers in ps_strings. kern.proc.args sysctl f
>Despite I made a request not long ago[1], I'm looking for
>documentation to create the ps_strings structure man page because
>isn't covered in other man page such e.g. execve(2). So, I'm
>interested to know for what it's currently used.
Nothing. (Well, backwards compatibility, depending on how
I have been experimenting with using the UMA (slab) allocator for
special-purpose physical address ranges. (The underlying issue is
that we need zone-like and/or mbuf-like data structures to talk to
hardware that has "special needs" in terms of which physical pages
it can in turn use. Each device
(Durn mailing list software, eating attachments... there are just
the two so I will just send them one at a time here. I took the
individual people off the to/cc since presumably you all got the
attachments already.)
Date: Thu, 27 Jun 2013 18:49:29 -0600
Subject: [PATCH 2/2] increase physical an
(Durn mailing list software, eating attachments... there are just
the two so I will just send them one at a time here. I took the
individual people off the to/cc since presumably you all got the
attachments already.)
Date: Sun, 14 Jul 2013 19:39:51 -0600
Subject: [PATCH 1/2] create_pagetables: co
Here's the split-up version with the additional comment
corrections.
Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>The changes associated with pt_p, pd_p and p4_p are cosmetic and IMHO
>detract from the meat of the change.
>
>My preference would be for the cosmetic changes to be committed
>separately from the changes that rearrange the KVA.
I can split these out.
>> - DMPDPphys = allocpages(firstaddr,
ons(+), 52 deletions(-)
Author: Chris Torek
Date: Thu Jun 27 18:49:29 2013 -0600
increase physical and virtual memory limits
Increase kernel VM space: go from .5 TB of KVA and 1 TB of direct
map, to 8 TB of KVA and 16 TB of direct map. However, we allocate
less direct map space
>for example, this host has has 32G of physical memory ...
>[snip - dmesg:]
>real memory = 34359738368 (32768 MB)
>avail memory = 32191340544 (30700 MB)
>[snip]
>and from sysctl:
>hw.physmem: 34284916736
>hw.usermem: 32964923392
>hw.realmem: 36507222016
>
>after setting
> hw.physmem=16G
>
>f
I went ahead and implemented the "ndmpdpphys" change I
had thought about. Here's that patch by itself.
At this point it might be reasonable to use the patch
without the AMD64_HUGE option, just increasing the KVM
area, as the direct map no longer consumes extra pages.
(There's a glitch in the com
[combining two messages and adding kib and alc to cc per Oliver Pinter]
>> the CPU's CR4 on entry to the kernel.
>It is %cr3.
Oops, well, easily fixed. :-)
>> (If we used bcopy() to copy the kernel pmap's NKPML4E and NDMPML4E
>> entries into the new pmap, the L3 pages would not have to be
>> phy
OK, I wasted :-) way too much time, but here's a text file that
can be comment-ified or stored somewhere alongside the code or
whatever...
(While drawing this I realized that there's at least one "wasted"
page if the machine has .5 TB or less: we can just leave zero
slots in the corresponding L4 d
>> .. (but I still needed the map I drew of the page tables...).
>care to share? :-)
It's on paper (I need to get a whiteboard...). If I can ASCIIfy it ...
Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
(Note: Last week I asked about this on the freebsd-current list.
It turned out slightly harder than I thought, as the 512GB kernel
virtual area is based on what fits into a single L4 page table
entry.)
I was asked to expand the kernel limits for amd64 systems. While
I do not have a system with en
>Not sure if the right answer is for drivers not to call ether_ifattach()
>until the point-of-no-failure (lots of drivers are wrong then) or
>initialize other parts earlier.
The other "obvious" method is to rearrange the sysinit priorities
(/sys/sys/kernel.h) so that all network domains are initia
>Can you provide a backtrace that leads to this?
Sure. In case it's not obvious, the __rw_rlock at the top of the
trace is working on a lock that has never been initialized (the
first of the two ipv4 PCBs).
Chris
Booting...
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current ba
I have been poking about with the bhyve virtualization code in
FreeBSD 10-current, and managed to crash FreeBSD during its
bootstrap process due to the fact that if_detach is called
from boot time configuration code, before the internal domain
system initialization has happened.
I added the follow
17 matches
Mail list logo
