On Sun, Apr 17, 2011 at 12:49 AM, Anton Maksimenkov <[email protected]>
wrote:
+ if (uvm.numof_free_kentries < 1) /*check to be safe*/
+ panic("uvm.numof_free_kentries[%d] < 1\n", uvm.numof_free_kentries);
>> 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).
I believe the above panic will occur whenever there is no free entry,
which will happen after the last "reserve" entry is used. If trying
to get more fails (most likely because the map is full), then we'll
use the reserve and the next allocation will fail. uvm_km_getpage can
fail, but it is unlikely. My laptop prints the warning message about
running out of static entries quite frequently, but never fails to get
a new page. An allocation failing when a map is out of space is not
just likely, it's a certainty.
I don't think the kmthread mechanism is perfect, but it's fairly well
understood and does not cause problems that I'm aware of. Are you
actually experiencing a problem where uvm_km_getpage is failing? That
is a theoretical concern, but I haven't seen evidence to suggest it's
a real problem. In general, I don't like any change that introduces a
new magic map or fixed limit. We suffered for years from various
subsystems reserving KVA that they didn't need (and other systems
failing when they ran out).
