2011/4/17 Ted Unangst <[email protected]>:
>> This kentry_map must be used only for kentries allocation. Since all
> This really isn't that much different than the static entries we have
> now. You are pre-reserving them.
No. Now, we have to trust to kmthread to preallocate pages. It is not
possible to predict when these preallocated pages will be exhausted.
And when it will be exhausted the bad situation created:
if (me == NULL) {
ne = uvm_km_getpage(0, &slowdown);
if (ne == NULL)
panic("uvm_mapent_alloc: cannot allocate map "
"entry");
While in my scheme that situation is recoverable (in fact, resolving
that situation was one of the primary targets).
Because if we can't allocate more kentries we still have reserved
kentry and it is safe - next time we may be luck and kentries will be
allocated.
+ if (uvm.numof_free_kentries == 1) {
+ me = (struct vm_map_entry
*)uvm_km_kmemalloc(kentry_map, NULL,
+ PAGE_SIZE, UVM_KMF_NOWAIT);
+ if (me == NULL) {
...
+ printf("kentry_map is EXHAUSTED, can't
allocate more static"
+ " entries\n");
+ simple_unlock(&uvm.kentry_lock);
+ splx(s);
+ goto out;
+ }
As you can see, there is no panic, just return error to the caller.
It is possible and allowed - when (1) kentry_map will be fully used or
if (2) there is no free physical page now.
First case may be resolved by increasing size of the kentry_map. Since
we !HAVE_PMAP_DIRECT some choise must be done. Either we setup big
size for kentry_map by default (eat virtual address space). Or we
setup not so big kentry_map and create some option to give the ability
to increase kentry_map size to the user.
Second case may be minimized if we reserve one physical page for that
case (see comment in diff).
>> Second, it may be decided to add some sysctl option to increase the
>> size of kentry_map.
> I think you will find this is the hard part. At least now, when out
> of static entries, you can steal a page and make more.
And as far as I remember, long time ago "steal a page and make more"
was deprecated in pmap module (are you about it)?
Ok, sysctl option may be tricky.
But compile option may be last choise. And that option will REALLY
helps, it works fully predictable - if you memory workload so big that
you see that you really need that much kentries, you can do it.
> This diff would take us back to the bad old days when running out of
entries led
> to a panic.
Totally conversely. As It was showed above, that situation completely
resolved and not fatal.
Other panics I add just for debug and to be safe that algorithm works
correctly. If all work correctly these panics does not appear even in
bad situation (kernel_map exhausted).
--
antonvm
