Re: svn commit: r323290 - head/sys/vm

[Mark Johnston]

On Sun, Sep 17, 2017 at 02:56:44PM +0200, Andreas Tobler wrote:
> On 17.09.17 00:28, Mark Johnston wrote:
> > Thanks. Could you please try applying the patch at the end of this email
> > and see if that fixes the issue? I have not yet tried to compile it,
> > sorry.
> 
> Excellent! I can confirm the two platforms, 32- and 64-bit powerpc, are 
> back to life. Both are running since a few hours and perfom ports 
> rebuild now.
> 
> Thank you very much for your prompt response and help.

Thanks Andreas, committed as r323676.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r323290 - head/sys/vm

[Andreas Tobler]

On 17.09.17 00:28, Mark Johnston wrote:

On Sat, Sep 16, 2017 at 09:01:56PM +0200, Andreas Tobler wrote:

On 14.09.17 22:32, Mark Johnston wrote:

On Thu, Sep 14, 2017 at 09:51:17PM +0200, Andreas Tobler wrote:

Hi Mark,

On 07.09.17 23:43, Mark Johnston wrote:

Author: markj
Date: Thu Sep  7 21:43:39 2017
New Revision: 323290
URL: https://svnweb.freebsd.org/changeset/base/323290

Log:
 Speed up vm_page_array initialization.
 
 We currently initialize the vm_page array in three passes: one to zero

 the array, one to initialize the "order" field of each page (necessary
 when inserting them into the vm_phys buddy allocator one-by-one), and
 one to initialize the remaining non-zero fields and individually insert
 each page into the allocator.
 
 Merge the three passes into one following a suggestion from alc:

 initialize vm_page fields in a single pass, and use vm_phys_free_contig()
 to efficiently insert physical memory segments into the buddy allocator.
 This reduces the initialization time to a third or a quarter of what it
 was before on most systems that I tested.
 
 Reviewed by:	alc, kib

 MFC after: 3 weeks
 Differential Revision: https://reviews.freebsd.org/D12248

Modified:
 head/sys/vm/vm_page.c
 head/sys/vm/vm_phys.c
 head/sys/vm/vm_phys.h


I just found out that this commit breaks booting my powerpc64 Quad G5.
It hangs, pressing ctrl-t shows: cmd: sh [*vm active pagequeue].

Sometimes it hangs earlier when the kbd is not there yet (usb), then I
can't get the process/task where it hangs.

Note, this kernel is compiled with the default gcc (4.2.1-FreeBSD)

Any ideas how to find out what's wrong?


Are you able to break into DDB when the hang occurs? If so, the output
of "show page" would be helpful.


Unfortunately not from the beginning. The keyboard is usb and it gets
installed late. Once it survives the loading of the kbd and co, I can
enter into ddb. But it is a trial and error. So far I didn't succeed to
come that far.


Are you running with INVARIANTS configured? If not, please try that.


The above was w/o INVARIANTS. With invariants the kernel panics
immediately after boot, see pic.


Thanks. Could you please try applying the patch at the end of this email
and see if that fixes the issue? I have not yet tried to compile it,
sorry.


Excellent! I can confirm the two platforms, 32- and 64-bit powerpc, are 
back to life. Both are running since a few hours and perfom ports 
rebuild now.


Thank you very much for your prompt response and help.

Andreas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r323290 - head/sys/vm

[Mark Johnston]

On Sat, Sep 16, 2017 at 09:01:56PM +0200, Andreas Tobler wrote:
> On 14.09.17 22:32, Mark Johnston wrote:
> > On Thu, Sep 14, 2017 at 09:51:17PM +0200, Andreas Tobler wrote:
> >> Hi Mark,
> >>
> >> On 07.09.17 23:43, Mark Johnston wrote:
> >>> Author: markj
> >>> Date: Thu Sep  7 21:43:39 2017
> >>> New Revision: 323290
> >>> URL: https://svnweb.freebsd.org/changeset/base/323290
> >>>
> >>> Log:
> >>> Speed up vm_page_array initialization.
> >>> 
> >>> We currently initialize the vm_page array in three passes: one to zero
> >>> the array, one to initialize the "order" field of each page (necessary
> >>> when inserting them into the vm_phys buddy allocator one-by-one), and
> >>> one to initialize the remaining non-zero fields and individually 
> >>> insert
> >>> each page into the allocator.
> >>> 
> >>> Merge the three passes into one following a suggestion from alc:
> >>> initialize vm_page fields in a single pass, and use 
> >>> vm_phys_free_contig()
> >>> to efficiently insert physical memory segments into the buddy 
> >>> allocator.
> >>> This reduces the initialization time to a third or a quarter of what 
> >>> it
> >>> was before on most systems that I tested.
> >>> 
> >>> Reviewed by:  alc, kib
> >>> MFC after:3 weeks
> >>> Differential Revision:https://reviews.freebsd.org/D12248
> >>>
> >>> Modified:
> >>> head/sys/vm/vm_page.c
> >>> head/sys/vm/vm_phys.c
> >>> head/sys/vm/vm_phys.h
> >>
> >> I just found out that this commit breaks booting my powerpc64 Quad G5.
> >> It hangs, pressing ctrl-t shows: cmd: sh [*vm active pagequeue].
> >>
> >> Sometimes it hangs earlier when the kbd is not there yet (usb), then I
> >> can't get the process/task where it hangs.
> >>
> >> Note, this kernel is compiled with the default gcc (4.2.1-FreeBSD)
> >>
> >> Any ideas how to find out what's wrong?
> > 
> > Are you able to break into DDB when the hang occurs? If so, the output
> > of "show page" would be helpful.
> 
> Unfortunately not from the beginning. The keyboard is usb and it gets 
> installed late. Once it survives the loading of the kbd and co, I can 
> enter into ddb. But it is a trial and error. So far I didn't succeed to 
> come that far.
> 
> > Are you running with INVARIANTS configured? If not, please try that.
> 
> The above was w/o INVARIANTS. With invariants the kernel panics 
> immediately after boot, see pic.

Thanks. Could you please try applying the patch at the end of this email
and see if that fixes the issue? I have not yet tried to compile it,
sorry.

> 
> >> The previous revision, r323289 seems stable, at least it survived
> >> several kernel builds.
> > 
> > Could you apply the patch below and capture the first page or so of
> > output from after the kernel starts booting?
> 
> I applied this diff and you see its output on the pic:
> 
> https://people.freebsd.org/~andreast/r323290_generic64_with_dbg_patch.jpg
> 
> I try now to get that far that I have a kbd and capture a 'show page'.

I don't think that's necessary anymore given the information provided in
the picture.

diff --git a/sys/powerpc/aim/mmu_oea.c b/sys/powerpc/aim/mmu_oea.c
index 04066418fcc1..b576474fcd1d 100644
--- a/sys/powerpc/aim/mmu_oea.c
+++ b/sys/powerpc/aim/mmu_oea.c
@@ -287,6 +287,7 @@ boolean_t moea_is_referenced(mmu_t, vm_page_t);
 int moea_ts_referenced(mmu_t, vm_page_t);
 vm_offset_t moea_map(mmu_t, vm_offset_t *, vm_paddr_t, vm_paddr_t, int);
 boolean_t moea_page_exists_quick(mmu_t, pmap_t, vm_page_t);
+void moea_page_init(mmu_t, vm_page_t);
 int moea_page_wired_mappings(mmu_t, vm_page_t);
 void moea_pinit(mmu_t, pmap_t);
 void moea_pinit0(mmu_t, pmap_t);
@@ -334,6 +335,7 @@ static mmu_method_t moea_methods[] = {
MMUMETHOD(mmu_ts_referenced,moea_ts_referenced),
MMUMETHOD(mmu_map,  moea_map),
MMUMETHOD(mmu_page_exists_quick,moea_page_exists_quick),
+   MMUMETHOD(mmu_page_init,moea_page_init),
MMUMETHOD(mmu_page_wired_mappings,moea_page_wired_mappings),
MMUMETHOD(mmu_pinit,moea_pinit),
MMUMETHOD(mmu_pinit0,   moea_pinit0),
@@ -1594,6 +1596,15 @@ moea_page_exists_quick(mmu_t mmu, pmap_t pmap, vm_page_t 
m)
return (rv);
 }
 
+void
+moea_page_init(mmu_t mmu __unused, vm_page_t m)
+{
+
+   m->md.mdpg_attrs = 0;
+   m->md.mdpg_cache_attrs = VM_MEMATTR_DEFAULT;
+   LIST_INIT(>md.mdpg_pvoh);
+}
+
 /*
  * Return the number of managed mappings to the given physical page
  * that are wired.
diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c
index c0461ff57453..28c9c79916f1 100644
--- a/sys/powerpc/aim/mmu_oea64.c
+++ b/sys/powerpc/aim/mmu_oea64.c
@@ -251,6 +251,7 @@ boolean_t moea64_is_referenced(mmu_t, vm_page_t);
 int moea64_ts_referenced(mmu_t, vm_page_t);
 vm_offset_t moea64_map(mmu_t, vm_offset_t *, vm_paddr_t, vm_paddr_t, int);
 boolean_t moea64_page_exists_quick(mmu_t, pmap_t, vm_page_t);

Re: svn commit: r323290 - head/sys/vm

[Andreas Tobler]

On 16.09.17 22:32, Justin Hibbits wrote:



On Sep 16, 2017 14:02, "Andreas Tobler" > wrote:


On 14.09.17 22:32, Mark Johnston wrote:

On Thu, Sep 14, 2017 at 09:51:17PM +0200, Andreas Tobler wrote:

Hi Mark,

On 07.09.17 23:43, Mark Johnston wrote:

Author: markj
Date: Thu Sep  7 21:43:39 2017
New Revision: 323290
URL: https://svnweb.freebsd.org/changeset/base/323290


Log:
     Speed up vm_page_array initialization.
         We currently initialize the vm_page array in
three passes: one to zero
     the array, one to initialize the "order" field of
each page (necessary
     when inserting them into the vm_phys buddy
allocator one-by-one), and
     one to initialize the remaining non-zero fields and
individually insert
     each page into the allocator.
         Merge the three passes into one following a
suggestion from alc:
     initialize vm_page fields in a single pass, and use
vm_phys_free_contig()
     to efficiently insert physical memory segments into
the buddy allocator.
     This reduces the initialization time to a third or
a quarter of what it
     was before on most systems that I tested.
         Reviewed by:    alc, kib
     MFC after:  3 weeks
     Differential Revision:
https://reviews.freebsd.org/D12248


Modified:
     head/sys/vm/vm_page.c
     head/sys/vm/vm_phys.c
     head/sys/vm/vm_phys.h


I just found out that this commit breaks booting my
powerpc64 Quad G5.
It hangs, pressing ctrl-t shows: cmd: sh [*vm active pagequeue].

Sometimes it hangs earlier when the kbd is not there yet
(usb), then I
can't get the process/task where it hangs.

Note, this kernel is compiled with the default gcc
(4.2.1-FreeBSD)

Any ideas how to find out what's wrong?


Are you able to break into DDB when the hang occurs? If so, the
output
of "show page" would be helpful.


Unfortunately not from the beginning. The keyboard is usb and it
gets installed late. Once it survives the loading of the kbd and co,
I can enter into ddb. But it is a trial and error. So far I didn't
succeed to come that far.


What about using dcons? That's saved me many times when I couldn't break 
into ddb from the console.


Might be worth a try, but as you might have seen on the pic, the panic 
happens immediately after printing the banner. At that time no driver is 
available. It might work when I try w/o invariants and have luck and get 
past the fwohci init.


Thx,
Andreas

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r323290 - head/sys/vm

[Justin Hibbits]

On Sep 16, 2017 14:02, "Andreas Tobler"  wrote:

On 14.09.17 22:32, Mark Johnston wrote:

> On Thu, Sep 14, 2017 at 09:51:17PM +0200, Andreas Tobler wrote:
>
>> Hi Mark,
>>
>> On 07.09.17 23:43, Mark Johnston wrote:
>>
>>> Author: markj
>>> Date: Thu Sep  7 21:43:39 2017
>>> New Revision: 323290
>>> URL: https://svnweb.freebsd.org/changeset/base/323290
>>>
>>> Log:
>>> Speed up vm_page_array initialization.
>>> We currently initialize the vm_page array in three passes: one
>>> to zero
>>> the array, one to initialize the "order" field of each page
>>> (necessary
>>> when inserting them into the vm_phys buddy allocator one-by-one), and
>>> one to initialize the remaining non-zero fields and individually
>>> insert
>>> each page into the allocator.
>>> Merge the three passes into one following a suggestion from alc:
>>> initialize vm_page fields in a single pass, and use
>>> vm_phys_free_contig()
>>> to efficiently insert physical memory segments into the buddy
>>> allocator.
>>> This reduces the initialization time to a third or a quarter of what
>>> it
>>> was before on most systems that I tested.
>>> Reviewed by:alc, kib
>>> MFC after:  3 weeks
>>> Differential Revision:  https://reviews.freebsd.org/D12248
>>>
>>> Modified:
>>> head/sys/vm/vm_page.c
>>> head/sys/vm/vm_phys.c
>>> head/sys/vm/vm_phys.h
>>>
>>
>> I just found out that this commit breaks booting my powerpc64 Quad G5.
>> It hangs, pressing ctrl-t shows: cmd: sh [*vm active pagequeue].
>>
>> Sometimes it hangs earlier when the kbd is not there yet (usb), then I
>> can't get the process/task where it hangs.
>>
>> Note, this kernel is compiled with the default gcc (4.2.1-FreeBSD)
>>
>> Any ideas how to find out what's wrong?
>>
>
> Are you able to break into DDB when the hang occurs? If so, the output
> of "show page" would be helpful.
>

Unfortunately not from the beginning. The keyboard is usb and it gets
installed late. Once it survives the loading of the kbd and co, I can enter
into ddb. But it is a trial and error. So far I didn't succeed to come that
far.


What about using dcons? That's saved me many times when I couldn't break
into ddb from the console.



Are you running with INVARIANTS configured? If not, please try that.
>

The above was w/o INVARIANTS. With invariants the kernel panics immediately
after boot, see pic.


The previous revision, r323289 seems stable, at least it survived
>> several kernel builds.
>>
>
> Could you apply the patch below and capture the first page or so of
> output from after the kernel starts booting?
>

I applied this diff and you see its output on the pic:

https://people.freebsd.org/~andreast/r323290_generic64_with_dbg_patch.jpg

I try now to get that far that I have a kbd and capture a 'show page'.

Thanks,
Andreas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r323290 - head/sys/vm

[Andreas Tobler]

On 14.09.17 22:32, Mark Johnston wrote:

On Thu, Sep 14, 2017 at 09:51:17PM +0200, Andreas Tobler wrote:

Hi Mark,

On 07.09.17 23:43, Mark Johnston wrote:

Author: markj
Date: Thu Sep  7 21:43:39 2017
New Revision: 323290
URL: https://svnweb.freebsd.org/changeset/base/323290

Log:
Speed up vm_page_array initialization.

We currently initialize the vm_page array in three passes: one to zero

the array, one to initialize the "order" field of each page (necessary
when inserting them into the vm_phys buddy allocator one-by-one), and
one to initialize the remaining non-zero fields and individually insert
each page into the allocator.

Merge the three passes into one following a suggestion from alc:

initialize vm_page fields in a single pass, and use vm_phys_free_contig()
to efficiently insert physical memory segments into the buddy allocator.
This reduces the initialization time to a third or a quarter of what it
was before on most systems that I tested.

Reviewed by:	alc, kib

MFC after:  3 weeks
Differential Revision:  https://reviews.freebsd.org/D12248

Modified:
head/sys/vm/vm_page.c
head/sys/vm/vm_phys.c
head/sys/vm/vm_phys.h


I just found out that this commit breaks booting my powerpc64 Quad G5.
It hangs, pressing ctrl-t shows: cmd: sh [*vm active pagequeue].

Sometimes it hangs earlier when the kbd is not there yet (usb), then I
can't get the process/task where it hangs.

Note, this kernel is compiled with the default gcc (4.2.1-FreeBSD)

Any ideas how to find out what's wrong?


Are you able to break into DDB when the hang occurs? If so, the output
of "show page" would be helpful.


Unfortunately not from the beginning. The keyboard is usb and it gets 
installed late. Once it survives the loading of the kbd and co, I can 
enter into ddb. But it is a trial and error. So far I didn't succeed to 
come that far.



Are you running with INVARIANTS configured? If not, please try that.


The above was w/o INVARIANTS. With invariants the kernel panics 
immediately after boot, see pic.



The previous revision, r323289 seems stable, at least it survived
several kernel builds.


Could you apply the patch below and capture the first page or so of
output from after the kernel starts booting?


I applied this diff and you see its output on the pic:

https://people.freebsd.org/~andreast/r323290_generic64_with_dbg_patch.jpg

I try now to get that far that I have a kbd and capture a 'show page'.

Thanks,
Andreas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r323290 - head/sys/vm

[Mark Johnston]

On Thu, Sep 14, 2017 at 09:51:17PM +0200, Andreas Tobler wrote:
> Hi Mark,
> 
> On 07.09.17 23:43, Mark Johnston wrote:
> > Author: markj
> > Date: Thu Sep  7 21:43:39 2017
> > New Revision: 323290
> > URL: https://svnweb.freebsd.org/changeset/base/323290
> > 
> > Log:
> >Speed up vm_page_array initialization.
> >
> >We currently initialize the vm_page array in three passes: one to zero
> >the array, one to initialize the "order" field of each page (necessary
> >when inserting them into the vm_phys buddy allocator one-by-one), and
> >one to initialize the remaining non-zero fields and individually insert
> >each page into the allocator.
> >
> >Merge the three passes into one following a suggestion from alc:
> >initialize vm_page fields in a single pass, and use vm_phys_free_contig()
> >to efficiently insert physical memory segments into the buddy allocator.
> >This reduces the initialization time to a third or a quarter of what it
> >was before on most systems that I tested.
> >
> >Reviewed by: alc, kib
> >MFC after:   3 weeks
> >Differential Revision:   https://reviews.freebsd.org/D12248
> > 
> > Modified:
> >head/sys/vm/vm_page.c
> >head/sys/vm/vm_phys.c
> >head/sys/vm/vm_phys.h
> 
> I just found out that this commit breaks booting my powerpc64 Quad G5.
> It hangs, pressing ctrl-t shows: cmd: sh [*vm active pagequeue].
> 
> Sometimes it hangs earlier when the kbd is not there yet (usb), then I 
> can't get the process/task where it hangs.
> 
> Note, this kernel is compiled with the default gcc (4.2.1-FreeBSD)
> 
> Any ideas how to find out what's wrong?

Are you able to break into DDB when the hang occurs? If so, the output
of "show page" would be helpful.

Are you running with INVARIANTS configured? If not, please try that.

> The previous revision, r323289 seems stable, at least it survived 
> several kernel builds.

Could you apply the patch below and capture the first page or so of
output from after the kernel starts booting?

diff --git a/sys/vm/vm_page.c b/sys/vm/vm_page.c
index fda8d1cf37f7..6862195c3e9c 100644
--- a/sys/vm/vm_page.c
+++ b/sys/vm/vm_page.c
@@ -648,8 +648,11 @@ vm_page_startup(vm_offset_t vaddr)
 * Add physical memory segments corresponding to the available
 * physical pages.
 */
-   for (i = 0; phys_avail[i + 1] != 0; i += 2)
+   for (i = 0; phys_avail[i + 1] != 0; i += 2) {
+   printf("adding phys_avail seg %#jx - %#jx\n",
+   phys_avail[i], phys_avail[i + 1]);
vm_phys_add_seg(phys_avail[i], phys_avail[i + 1]);
+   }
 
/*
 * Initialize the physical memory allocator.
@@ -664,6 +667,8 @@ vm_page_startup(vm_offset_t vaddr)
vm_cnt.v_free_count = 0;
for (segind = 0; segind < vm_phys_nsegs; segind++) {
seg = _phys_segs[segind];
+   printf("inserting seg %d: %#jx - %#jx\n", segind,
+   (uintmax_t)seg->start, (uintmax_t)seg->end);
for (pa = seg->start; pa < seg->end; pa += PAGE_SIZE)
vm_phys_init_page(pa);
 
@@ -679,6 +684,7 @@ vm_page_startup(vm_offset_t vaddr)
seg->end > phys_avail[i + 1])
continue;
 
+   printf("inserting seg %d into vm_phys\n", segind);
m = seg->first_page;
pagecount = (u_long)atop(seg->end - seg->start);
 
@@ -694,6 +700,7 @@ vm_page_startup(vm_offset_t vaddr)
break;
}
}
+   printf("v_free_count: %u\n", vm_cnt.v_free_count);
 
/*
 * Remove blacklisted pages from the physical memory allocator.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r323290 - head/sys/vm

[Andreas Tobler]

Hi Mark,

On 07.09.17 23:43, Mark Johnston wrote:

Author: markj
Date: Thu Sep  7 21:43:39 2017
New Revision: 323290
URL: https://svnweb.freebsd.org/changeset/base/323290

Log:
   Speed up vm_page_array initialization.
   
   We currently initialize the vm_page array in three passes: one to zero

   the array, one to initialize the "order" field of each page (necessary
   when inserting them into the vm_phys buddy allocator one-by-one), and
   one to initialize the remaining non-zero fields and individually insert
   each page into the allocator.
   
   Merge the three passes into one following a suggestion from alc:

   initialize vm_page fields in a single pass, and use vm_phys_free_contig()
   to efficiently insert physical memory segments into the buddy allocator.
   This reduces the initialization time to a third or a quarter of what it
   was before on most systems that I tested.
   
   Reviewed by:	alc, kib

   MFC after:   3 weeks
   Differential Revision:   https://reviews.freebsd.org/D12248

Modified:
   head/sys/vm/vm_page.c
   head/sys/vm/vm_phys.c
   head/sys/vm/vm_phys.h


I just found out that this commit breaks booting my powerpc64 Quad G5.
It hangs, pressing ctrl-t shows: cmd: sh [*vm active pagequeue].

Sometimes it hangs earlier when the kbd is not there yet (usb), then I 
can't get the process/task where it hangs.


Note, this kernel is compiled with the default gcc (4.2.1-FreeBSD)

Any ideas how to find out what's wrong?
The previous revision, r323289 seems stable, at least it survived 
several kernel builds.


TIA,
Andreas
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

svn commit: r323290 - head/sys/vm

[Mark Johnston]

Author: markj
Date: Thu Sep  7 21:43:39 2017
New Revision: 323290
URL: https://svnweb.freebsd.org/changeset/base/323290

Log:
  Speed up vm_page_array initialization.
  
  We currently initialize the vm_page array in three passes: one to zero
  the array, one to initialize the "order" field of each page (necessary
  when inserting them into the vm_phys buddy allocator one-by-one), and
  one to initialize the remaining non-zero fields and individually insert
  each page into the allocator.
  
  Merge the three passes into one following a suggestion from alc:
  initialize vm_page fields in a single pass, and use vm_phys_free_contig()
  to efficiently insert physical memory segments into the buddy allocator.
  This reduces the initialization time to a third or a quarter of what it
  was before on most systems that I tested.
  
  Reviewed by:  alc, kib
  MFC after:3 weeks
  Differential Revision:https://reviews.freebsd.org/D12248

Modified:
  head/sys/vm/vm_page.c
  head/sys/vm/vm_phys.c
  head/sys/vm/vm_phys.h

Modified: head/sys/vm/vm_page.c
==
--- head/sys/vm/vm_page.c   Thu Sep  7 21:33:27 2017(r323289)
+++ head/sys/vm/vm_page.c   Thu Sep  7 21:43:39 2017(r323290)
@@ -429,17 +429,15 @@ vm_page_domain_init(struct vm_domain *vmd)
 vm_offset_t
 vm_page_startup(vm_offset_t vaddr)
 {
-   vm_offset_t mapped;
-   vm_paddr_t high_avail, low_avail, page_range, size;
-   vm_paddr_t new_end;
-   int i;
-   vm_paddr_t pa;
-   vm_paddr_t last_pa;
+   struct vm_domain *vmd;
+   struct vm_phys_seg *seg;
+   vm_page_t m;
char *list, *listend;
-   vm_paddr_t end;
-   vm_paddr_t biggestsize;
-   int biggestone;
-   int pages_per_zone;
+   vm_offset_t mapped;
+   vm_paddr_t end, high_avail, low_avail, new_end, page_range, size;
+   vm_paddr_t biggestsize, last_pa, pa;
+   u_long pagecount;
+   int biggestone, i, pages_per_zone, segind;
 
biggestsize = 0;
biggestone = 0;
@@ -519,6 +517,8 @@ vm_page_startup(vm_offset_t vaddr)
vm_page_dump = (void *)(uintptr_t)pmap_map(, new_end,
new_end + vm_page_dump_size, VM_PROT_READ | VM_PROT_WRITE);
bzero((void *)vm_page_dump, vm_page_dump_size);
+#else
+   (void)last_pa;
 #endif
 #if defined(__aarch64__) || defined(__amd64__) || defined(__mips__)
/*
@@ -623,7 +623,9 @@ vm_page_startup(vm_offset_t vaddr)
new_end = trunc_page(end - page_range * sizeof(struct vm_page));
mapped = pmap_map(, new_end, end,
VM_PROT_READ | VM_PROT_WRITE);
-   vm_page_array = (vm_page_t) mapped;
+   vm_page_array = (vm_page_t)mapped;
+   vm_page_array_size = page_range;
+
 #if VM_NRESERVLEVEL > 0
/*
 * Allocate physical memory for the reservation management system's
@@ -650,33 +652,52 @@ vm_page_startup(vm_offset_t vaddr)
vm_phys_add_seg(phys_avail[i], phys_avail[i + 1]);
 
/*
-* Clear all of the page structures
-*/
-   bzero((caddr_t) vm_page_array, page_range * sizeof(struct vm_page));
-   for (i = 0; i < page_range; i++)
-   vm_page_array[i].order = VM_NFREEORDER;
-   vm_page_array_size = page_range;
-
-   /*
 * Initialize the physical memory allocator.
 */
vm_phys_init();
 
/*
-* Add every available physical page that is not blacklisted to
-* the free lists.
+* Initialize the page structures and add every available page to the
+* physical memory allocator's free lists.
 */
vm_cnt.v_page_count = 0;
vm_cnt.v_free_count = 0;
-   for (i = 0; phys_avail[i + 1] != 0; i += 2) {
-   pa = phys_avail[i];
-   last_pa = phys_avail[i + 1];
-   while (pa < last_pa) {
-   vm_phys_add_page(pa);
-   pa += PAGE_SIZE;
+   for (segind = 0; segind < vm_phys_nsegs; segind++) {
+   seg = _phys_segs[segind];
+   for (pa = seg->start; pa < seg->end; pa += PAGE_SIZE)
+   vm_phys_init_page(pa);
+
+   /*
+* Add the segment to the free lists only if it is covered by
+* one of the ranges in phys_avail.  Because we've added the
+* ranges to the vm_phys_segs array, we can assume that each
+* segment is either entirely contained in one of the ranges,
+* or doesn't overlap any of them.
+*/
+   for (i = 0; phys_avail[i + 1] != 0; i += 2) {
+   if (seg->start < phys_avail[i] ||
+   seg->end > phys_avail[i + 1])
+   continue;
+
+   m = seg->first_page;
+   pagecount = (u_long)atop(seg->end - seg->start);
+
+