(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,
Hi Chris,
On Sun, Jul 7, 2013 at 11:42 PM, Chris Torek wrote:
> Here is a final (I hope) version of the patch. I dropped the
> config option, but I added code to limit the "real" size of the
> direct map PDEs. The end result is that on small systems, this
> ties up 14 more pages (15 from increa
Here is a final (I hope) version of the patch. I dropped the
config option, but I added code to limit the "real" size of the
direct map PDEs. The end result is that on small systems, this
ties up 14 more pages (15 from increasing NKPML4E, but one
regained because the new static variable ndmpdpphy
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
On Wed, Jun 26, 2013 at 10:11:44AM -0600, Chris Torek wrote:
> diff --git a/conf/options.amd64 b/conf/options.amd64
> index 90348b7..f3ce505 100644
> --- a/conf/options.amd64
> +++ b/conf/options.amd64
> @@ -1,6 +1,7 @@
> # $FreeBSD$
> # Options specific to AMD64 platform kernels
>
> +AMD64_HUG
On Thu, Jun 27, 2013 at 03:23:36PM -0600, Chris Torek wrote:
> 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...
I think it would be a nice addition to the VM article in the doc
collection. The content is
On 6/27/13, Chris Torek wrote:
> 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
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
On 6/27/13 12:11 AM, Chris Torek wrote:
[...]
them (but I still needed the map I drew of the page tables...).
care to share? :-)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, sen
(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
15 matches
Mail list logo
