RMI status

[Randall Stewart]

JC:

Yeah, I figure you must be hitting something like that.
The original hack was put in place just to find a easy way
to use some of the memory above 512Meg on Octeon. The intent
was always to go to n32 or n64 so we could use the full address
space.

I believe you will find comments in the code at one point that
say the kernel will crash if it gets a page above 512Meg...

Now I see two ways forward...

Either we make something like you mentioned.. i.e. you setup
and pre-reserve a bunch of the pages for the kernel ahead of
time i.e. some sort of special allocation.

Or

We ignore this issue until we get to 64bit... I think the true
answer is being in a mode such as n64 where you have a xseg that
can address all the memory....


I think an overall plan to go to one of the new ABI's is a
better one then make more special hacks (memory allocator)..


R



On Feb 15, 2010, at 7:51 AM, C. Jayachandran wrote:

> On Thu, Feb 11, 2010 at 10:45 PM, C. Jayachandran
> <c.jayachandran at gmail.com> wrote:
>> On Thu, Feb 11, 2010 at 9:08 PM, Randall Stewart <rrs at 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.
>

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)