Re: contigmalloc for low address in SI_SUB_KMEM

[qhwt@xxxxxxxxxxxxx]

On Tue, Sep 16, 2003 at 12:36:18PM -0700, Matthew Dillon wrote:
> 
> :But if this is the case, removing
> :    options         NO_KMEM_MAP
> :    options         USE_SLAB_ALLOCATOR
> :fixes the contigmalloc(), no? When I first noticed the error message,
> :I didn't have these in my kernel config file.
> :
> :>     The solution is to try to figure out why that is occuring.
> :
> :Absolutely :)
> :...
> :I'm going to dig into FreeBSD-STABLE code and how it behaves differently
> :from ours.
> 
>     This should all be fixed now in vm/vm_page.c 1.10.  Make sure you have
>     cleared any priority patches I posted and update your tree.
> 
>     In FreeBSD we made a number of commits that had issues with
>     VM_ALLOC_ZERO verses not.  In the last commit I made to DragonFly
>     I adjusted the code so both VM_ALLOC_ZERO and non-VM_ALLOC_ZERO 
>     allocations should obtain high addresses first.  The new vm_add_new_page()
>     and related code adds memory to the free lists from low-to-high
>     physical addresses, to both ends of the list, building the free page list
>     outwards from the center so higher addresses should be at both ends.
> 
>     If it still isn't working properly for you then perhaps the phys_avail[]
>     array is not in ascending order.  To find out you can add a debugging
>     printf() to the for() loop in vm_page_startup().

Yes, your fix is working fine here, as I replied to you on kernel@ list.

The message you replied was originally sent on Septemper 6th,
but have stayed on myrealbox server until now. Unfortunately at that time,
myrealbox.com mail server seemed to be under heavy attack from virus-
infected servers and misconfigured virus scanners(or maybe they were
doing some system upgrade; they usually don't make an announcement
unless the change affects users seriously). My message managed
to be queued, but didn't reach dragonflybsd.org's MX for a while, so
I thought it was dropped. I'm not familiar with how mail messages are
dealt with inside myrealbox, but sometimes they seems to deliver those
postponed messages several days later.

At that time I wrote that message, I was completely misunderstanding how
VM system is working(maybe I still am:), so please disregard that message.

And I'm really sorry to have bothered you.