Date: Mon, 15 Feb 2010 21:21:58 +0530 From: "C. Jayachandran" <c.jayachandran@gmail.com> To: Randall Stewart <rrs@lakerest.net>, freebsd-mips@freebsd.org Subject: Re: RMI status Message-ID: <98a59be81002150751l2871e825ycbc9dda736870e4f@mail.gmail.com> In-Reply-To: <98a59be81002110915l2fa64189g28f13f8ad39c9584@mail.gmail.com> References: <5709963B-3F83-44FE-991F-A3227A2052DC@lakerest.net> <98a59be81002110655y60ab4e8cj473f4b6ecf6f5ae4@mail.gmail.com> <A718B150-C815-414E-947D-9FD94830DD7D@lakerest.net> <98a59be81002110915l2fa64189g28f13f8ad39c9584@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 11, 2010 at 10:45 PM, C. Jayachandran
<c.jayachandran@gmail.com> wrote:
> On Thu, Feb 11, 2010 at 9:08 PM, Randall Stewart <rrs@lakerest.net> wrote:
>> Ahh.. I don't use a -jN since there is only one core
>> currently... That would use more memory... maybe running
>> the kernel out of memory below the magic 512Meg mark. If that
>> happens things will break...
>>
>
> I think you are right - I added the following patch (probably
> whitespace damaged) to trap this case and it certainly seems to get
> pages above 256M before it crashed(on XLR the default bootloader maps
> physmem from 0-256M after that is IO and flash mapping).
The two places where MIPS_PHYS_TO_CACHED(pa) is called where the
physical address is not checked to be less than
MIPS_KSEG0_LARGEST_PHYS are below:
mips/mips/pmap.c:pmap_pinit
| while ((ptdpg = vm_page_alloc(NULL, NUSERPGTBLS, req)) == NULL)
| VM_WAIT;
|
| ptdpg->valid = VM_PAGE_BITS_ALL;
|
| pmap->pm_segtab = (pd_entry_t *)
| MIPS_PHYS_TO_CACHED(VM_PAGE_TO_PHYS(ptdpg));
mips/mips/pmap.c:_pmap_allocpte
| if ((m = vm_page_alloc(NULL, ptepindex, req)) == NULL) {
| if (flags & M_WAITOK) {
|[...deleted..]
| pmap->pm_stats.resident_count++;
|
| ptepa = VM_PAGE_TO_PHYS(m);
| pteva = MIPS_PHYS_TO_CACHED(ptepa);
As I wrote earlier, I had added prints here, and we get addresses here
which are outside the direct mapped area when there is memory more than 512M
I cannot see how this can work, because vm_page_alloc can return pages
which can be above the maximum KSEG0 address, and we will crash in
this case..
I am trying to use 'vm_phys_alloc_contig' to allocated KSEG0 pages,
but I'm still figuring out how to use that correctly - and what the
performance penalty will be. Meanwhile, any ideas on this can be
fixed (or better, an explanation why this is not an issue) will be
very welcome.
Also, in RMI's FreeBSD 6.4 code, we had a platform specific version of
uma_small_alloc which would maintain a pool of kseg0 pages (using a
kernel thread), I think something like that would be useful here to
maintain a pool of kseg0 pages which can be used for page table too.
Thanks,
JC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98a59be81002150751l2871e825ycbc9dda736870e4f>