Yes.Why should userspace need to know if the kernel is shrinking memoryCool. This is a good approach for an initial patch but this raisesTwo ways in my mind:
concerns about efficiently managing kernel memory usage -- the data area
grows but never shrinks, and total possible usage increases per
backstore. (What if there are 1000?) Any ideas how we could also improve
these aspects of the design? (Global TCMU data area usage limit?)
The first:
How about by setting a threshold cmd(SHRINK cmd), something likes
the PAD cmd, to tell the userspace runner try to shrink the memories?
allocated to the data area? Userspace knows about memory described in
iovecs for in-flight cmds, we shouldn't need its cooperation to free
other allocated parts of the data area.
But, We likely don't want to release memory from the data area anyways
while active, in any case. How about if we set a timer when active
commands go to zero, and then reduce data area to some minimum if no new
cmds come in before timer expires?
Yes, agree.When the runner get the SHRINK cmd, it will try to remmap uio0's ringUserspace should not need to remap the region in order for the kernel to
buffer(?). Then the kernel will get chance to shrink the memories....
The second:
Try to extern the data area by using /dev/uio1, we could remmap the
uio1 device when need, so it will be easy to get a chance to shrink the
memories in uio1.
free and unmap pages from the region.
The only thing we need to watch out for is if blocks are referenced by
in-flight cmds, we can't free them or userspace will segfault.
So, if weSo, the problem is how to ummap the kfree()ed pages' ptes.
wait until there are no in-flight cmds, then it follows that the kernel
can free whatever it wants and userspace will not segfault.
-- Andy