Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Jun 2010 10:05:38 +0530
From:      "C. Jayachandran" <c.jayachandran@gmail.com>
To:        Alan Cox <alc@cs.rice.edu>
Cc:        "Jayachandran C." <jchandra@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Randall Stewart <rrs@lakerest.net>
Subject:   Re: svn commit: r208589 - head/sys/mips/mips
Message-ID:  <AANLkTil955Ek-a3tek4Ony9NqrK5l2j7lNA4baRVPBzb@mail.gmail.com>
In-Reply-To: <4C058145.3000707@cs.rice.edu>
References:  <201005271005.o4RA5eVu032269@svn.freebsd.org> <4C058145.3000707@cs.rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 2, 2010 at 3:23 AM, Alan Cox <alc@cs.rice.edu> wrote:
> On 5/27/2010 5:05 AM, Jayachandran C. wrote:
>>
>> Author: jchandra
>> Date: Thu May 27 10:05:40 2010
>> New Revision: 208589
>> URL: http://svn.freebsd.org/changeset/base/208589
>>
>> Log:
>> =A0 Call VM_WAIT in pmap_ptpgzone_allocf() if =A0M_WAITOK is set.
>> =A0 Removed unused variable.
>>
>> =A0 Approved by: rrs (mentor)
>>
>>
>
> I'm afraid that this will work some of the time, but not all of the time.
> =A0Specifically, there is no guarantee that any of the available free (or
> cached) pages after the VM_WAIT will fall within the range of suitable
> physical addresses. =A0Moreover, and perhaps most worrisome, is that this
> function could do a lot of spinning. =A0Every time this function sleeps a=
nd a
> single page is freed (or cached) by someone else, this function will be
> reawakened. =A0With a little bad luck, you could spin indefinitely.
>
> For essentially this reason, contigmalloc(), kmem_alloc_contig(), and
> kmem_alloc_attr() don't use VM_WAIT, but instead a function called
> vm_contig_grow_cache().

I had seen the vm_contig_grow_cache() usage, but could not use it as
it was defined as a static function.

I did not want to use contigmalloc()/kmem_alloc_contig() either,
because the pages in that memory region are already direct mapped and
setting up another mapping is not necessary. The overall idea is to
allocate pages in the direct mapped region for the page table entries
so that we don't take a TLB exception while accessing page tables
(which is costly as MIPS has a software TLB exception handler).

Can you suggest the right way to do this? I will make the changes and
send a patch for approval.

Thanks,
JC.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTil955Ek-a3tek4Ony9NqrK5l2j7lNA4baRVPBzb>