On Wed, Apr 06, 2011 at 12:12:35AM +0600, Anton Maksimenkov wrote:
> 2011/4/5 Anton Maksimenkov :
> > I have some idea related to allocator for (! __HAVE_PMAP_DIRECT) case.
> ...
> > My idea is how to resolve that loop by another way.
> > We must keep track the number of free kentries. And when we
2011/4/5 Anton Maksimenkov :
> I have some idea related to allocator for (! __HAVE_PMAP_DIRECT) case.
...
> My idea is how to resolve that loop by another way.
> We must keep track the number of free kentries. And when we see, in
> uvm_mapent_alloc(), that there is only 1 kentry remains then we mus
On Tue, Apr 5, 2011 at 8:05 AM, Anton Maksimenkov wrote:
> That is why kmthread exists?
No, but it's a nice side effect that we can use it to resolve the static kentry
problem.
The reason for kmthread is that we want to reduce the use of kmem_map
since it has problems with locking and recursion
2011/4/5 Artur Grabowski :
> - Use km_alloc for all backend allocations in pools.
> - Use km_alloc for the emergmency kentry allocations in uvm_mapent_alloc
> - Garbage collect uvm_km_getpage, uvm_km_getpage_pla and uvm_km_putpage
I have some idea related to allocator for (! __HAVE_PMAP_DIRECT)
On Mon, Apr 04, 2011 at 03:54:32PM -0600, Artur Grabowski wrote:
> First proper use of the new km_alloc.
>
> - Change pool constraints to use kmem_pa_mode instead of uvm_constraint_range
> - Use km_alloc for all backend allocations in pools.
> - Use km_alloc for the emergmency kentry allocation
First proper use of the new km_alloc.
- Change pool constraints to use kmem_pa_mode instead of uvm_constraint_range
- Use km_alloc for all backend allocations in pools.
- Use km_alloc for the emergmency kentry allocations in uvm_mapent_alloc
- Garbage collect uvm_km_getpage, uvm_km_getpage_pla
