:>
:> 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 r
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(
:>:
:>: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
:t
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
:
:
: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 vms
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
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_refcn
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
: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 f
:
: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 resource
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. F
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
:>: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
:>
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 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 decrem
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
th
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
17 matches
Mail list logo
