On 22-May-01 Matt Dillon wrote:
:Ok, then why not let the current shmexit() stay in exit1() as a hack to help
:free memory, but add in a check in vmspace_free() as well to catch any race
:conditions that may fall through the cracks? As long as we clear the shm
:pointer in struct vmspace when we
:
:
:On 22-May-01 Matt Dillon wrote:
::Ok, then why not let the current shmexit() stay in exit1() as a hack to help
::free memory, but add in a check in vmspace_free() as well to catch any race
::conditions that may fall through the cracks? As long as we clear the shm
::pointer in struct
On 22-May-01 Matt Dillon wrote:
:
:
:On 22-May-01 Matt Dillon wrote:
::Ok, then why not let the current shmexit() stay in exit1() as a hack to
::help
::free memory, but add in a check in vmspace_free() as well to catch any race
::conditions that may fall through the cracks? As long as we
::
::John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
:
: Huh? It doesn't look like the same algorithm to me.
:
:In exit1() we attempt to free resources early if we can. If we lose the race,
:we still clean it up in vmspace_free() called from cpu_wait(). If you check
:the
On 22-May-01 Matt Dillon wrote:
::
::John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
:
: Huh? It doesn't look like the same algorithm to me.
:
:In exit1() we attempt to free resources early if we can. If we lose the
:race,
:we still clean it up in vmspace_free() called from
:
: The whole point is to release resources as early as possible. Why would
: you ever want to intentionally introduce a race that will 'sometimes' be
: lost and thus cause a late resource release when you can just as easily
: completely guarentee that the resource will be
On 21-May-01 Brian F. Feldman wrote:
There's a certain issue that when several processes sharing a vmspace are
exiting at the same time, there is a race condition such that the shared
memory is going to be lost because the check for vm-vm_refcnt being the
check for the last decrement
This could explain a few bug reports I've had over the years in regards
to systems leaking swap space. Good find!
Hmmm. May I suggest an alternative?
* Keep the part that changes vm-vm_refcnt == 1 to
--vm-vm_refcnt == 0 when checking whether to free
the
:On 21-May-01 Brian F. Feldman wrote:
: There's a certain issue that when several processes sharing a vmspace are
: exiting at the same time, there is a race condition such that the shared
: memory is going to be lost because the check for vm-vm_refcnt being the
: check for the last decrement
On 21-May-01 Matt Dillon wrote:
:On 21-May-01 Brian F. Feldman wrote:
: There's a certain issue that when several processes sharing a vmspace are
: exiting at the same time, there is a race condition such that the shared
: memory is going to be lost because the check for vm-vm_refcnt being the
::John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
:
:That isn't the problem. The problem is that the process can block
:in between the 'if (vm-vm_refcnt == 1)' test in exit1(), and the
:actual vmspace_free() in cpu_exit() (which occurs after the process
:has been
On 21-May-01 Matt Dillon wrote:
::John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
:IOW, the vmspace refcount is being (ab)used for the shm stuff. Why not move
:the shmexit() to vmspace_free()? Hmm, I suppose the actual unmapping of all
:the user pages has this problem as
On Mon, May 21, 2001 at 12:35:17PM -0700, Matt Dillon wrote:
It's important to release resources as early as possible, so zombied
processes don't run the machine out of memory if a parent forgets to
reap its children.
I've found one other reason for releasing resources early. For
:
:On Mon, May 21, 2001 at 12:35:17PM -0700, Matt Dillon wrote:
:
: It's important to release resources as early as possible, so zombied
: processes don't run the machine out of memory if a parent forgets to
: reap its children.
:
:I've found one other reason for releasing resources
:Ok, then why not let the current shmexit() stay in exit1() as a hack to help
:free memory, but add in a check in vmspace_free() as well to catch any race
:conditions that may fall through the cracks? As long as we clear the shm
:pointer in struct vmspace when we free it then we won't be double
Matt Dillon [EMAIL PROTECTED] wrote:
:On 21-May-01 Brian F. Feldman wrote:
: There's a certain issue that when several processes sharing a vmspace are
: exiting at the same time, there is a race condition such that the shared
: memory is going to be lost because the check for vm-vm_refcnt
Matt Dillon [EMAIL PROTECTED] wrote:
This could explain a few bug reports I've had over the years in regards
to systems leaking swap space. Good find!
Hmmm. May I suggest an alternative?
* Keep the part that changes vm-vm_refcnt == 1 to
--vm-vm_refcnt == 0
There's a certain issue that when several processes sharing a vmspace are
exiting at the same time, there is a race condition such that the shared
memory is going to be lost because the check for vm-vm_refcnt being the
check for the last decrement happening before the last decrement is
18 matches
Mail list logo
