Allow larger CEQs (XCC)
authorBarret Rhoden <brho@cs.berkeley.edu>
Fri, 6 Jan 2017 19:19:43 +0000 (14:19 -0500)
committerBarret Rhoden <brho@cs.berkeley.edu>
Tue, 10 Jan 2017 00:01:40 +0000 (19:01 -0500)
commitb4521e610d7fed4d05f76aceb019f933874ba00a
tree068608091c518a867549fde49e4e768dc721ba2f
parent0362326de13b4934887b58cb95d868604881c648
Allow larger CEQs (XCC)

Previously, the user may have been punished for having a very large CEQ
event space.  This is the range of possible event IDs the CEQ would ever
see.  For FDs, technically the user might want NR_FILE_DESC_MAX (2^19).
That'd be about a 16 MB CEQ structure, and an O(2^19) recovery scan.

With this change, we only grow the CEQ's actual memory use on demand (soft
page fault) and only scan up to the max ever seen.  The memory tricks are
OK - the kernel needs to protect against PFs when accessing user memory
anyways, and it is safe for vcore context to have a soft PF on anonymous
memory.  (If we're OOM, we'd need to handle that regardless of whether or
not the user happened to be in vcore context).

Rebuild the world.  (At least glibc and dropbear.  Probably anything
multicore too).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/include/ros/ceq.h
kern/src/ceq.c
user/parlib/ceq.c