Arun Sharma writes:
> The daemons which are involved in freeing up pages during low memory
> conditions qualify as system daemons. Making sure that these daemons
> don't block avoids the deadlock.
>
> -Arun
The second solution involves a little more than that. Such as
blessing "normal
Arun Sharma writes:
> The daemons which are involved in freeing up pages during low memory
> conditions qualify as system daemons. Making sure that these daemons
> don't block avoids the deadlock.
>
> -Arun
The second solution involves a little more than that. Such as
blessing "norma
On Fri, Aug 13, 1999 at 03:04:43PM +0930, Mark Newton wrote:
> Arun Sharma wrote:
>
> > The second alternative - to mark system daemons as special
> > sounds much more attractive.
>
> Ok, now define the difference between "system daemons" and any other
> daemon (or, for that matter, any other p
Arun Sharma wrote:
> The second alternative - to mark system daemons as special
> sounds much more attractive.
Ok, now define the difference between "system daemons" and any other
daemon (or, for that matter, any other process).
- mark
Mark Newton Email
On Thu, Aug 12, 1999 at 12:02:19PM +0100, Tony Finch wrote:
> Matthew Dillon wrote:
> >
> >One solution would be to map clean R+W pages RO and force a write fault
> >to occur, allowing the system to recognize that there are too many dirty
> >pages in vm_fault before it is too late and
On Fri, Aug 13, 1999 at 03:04:43PM +0930, Mark Newton wrote:
> Arun Sharma wrote:
>
> > The second alternative - to mark system daemons as special
> > sounds much more attractive.
>
> Ok, now define the difference between "system daemons" and any other
> daemon (or, for that matter, any other
Arun Sharma wrote:
> The second alternative - to mark system daemons as special
> sounds much more attractive.
Ok, now define the difference between "system daemons" and any other
daemon (or, for that matter, any other process).
- mark
Mark Newton Emai
On Thu, Aug 12, 1999 at 12:02:19PM +0100, Tony Finch wrote:
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
> >
> >One solution would be to map clean R+W pages RO and force a write fault
> >to occur, allowing the system to recognize that there are too many dirty
> >pages in vm_fault before
Matthew Dillon wrote:
>
>One solution would be to map clean R+W pages RO and force a write fault
>to occur, allowing the system to recognize that there are too many dirty
>pages in vm_fault before it is too late and flush some of them. The
>downside of this is that, of course, we
Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
>One solution would be to map clean R+W pages RO and force a write fault
>to occur, allowing the system to recognize that there are too many dirty
>pages in vm_fault before it is too late and flush some of them. The
>downside of this is
:If the latter mmap.c is allowed to fill up filesystem, -current hangs in
:
:/kernel: pid 2 (pagedaemon), uid 0 on /: file system full
:/kernel: vnode_pager_putpages: I/O error 28
:/kernel: vnode_pager_putpages: residual I/O 16384 at 880
:
:...repeating the last two lines, gradually increasing pind
:If the latter mmap.c is allowed to fill up filesystem, -current hangs in
:
:/kernel: pid 2 (pagedaemon), uid 0 on /: file system full
:/kernel: vnode_pager_putpages: I/O error 28
:/kernel: vnode_pager_putpages: residual I/O 16384 at 880
:
:...repeating the last two lines, gradually increasing pin
:If the latter mmap.c is allowed to fill up filesystem, -current hangs in
:
:/kernel: pid 2 (pagedaemon), uid 0 on /: file system full
:/kernel: vnode_pager_putpages: I/O error 28
:/kernel: vnode_pager_putpages: residual I/O 16384 at 880
:
:...repeating the last two lines, gradually increasing pind
If the latter mmap.c is allowed to fill up filesystem, -current hangs in
/kernel: pid 2 (pagedaemon), uid 0 on /: file system full
/kernel: vnode_pager_putpages: I/O error 28
/kernel: vnode_pager_putpages: residual I/O 16384 at 880
...repeating the last two lines, gradually increasing pindex,
re
:>
:>He's trying to ask if this is a problem with the code in question or 3.2R's
:>mmap.
:
: That's better. It appears to be a classic resource related deadlock that
:is caused by the VFS code needing pages in order to page things out (and thus
:free up pages), but is unable to since no memory is
:If the latter mmap.c is allowed to fill up filesystem, -current hangs in
:
:/kernel: pid 2 (pagedaemon), uid 0 on /: file system full
:/kernel: vnode_pager_putpages: I/O error 28
:/kernel: vnode_pager_putpages: residual I/O 16384 at 880
:
:...repeating the last two lines, gradually increasing pin
If the latter mmap.c is allowed to fill up filesystem, -current hangs in
/kernel: pid 2 (pagedaemon), uid 0 on /: file system full
/kernel: vnode_pager_putpages: I/O error 28
/kernel: vnode_pager_putpages: residual I/O 16384 at 880
...repeating the last two lines, gradually increasing pindex,
r
:>
:>He's trying to ask if this is a problem with the code in question or 3.2R's
:>mmap.
:
: That's better. It appears to be a classic resource related deadlock that
:is caused by the VFS code needing pages in order to page things out (and thus
:free up pages), but is unable to since no memory i
> >He's trying to ask if this is a problem with the code in question or 3.2R's
> >mmap.
>
>That's better. It appears to be a classic resource related deadlock that
> is caused by the VFS code needing pages in order to page things out (and thus
> free up pages), but is unable to since no memory
>Looks like Oleg made a mistake in posting the code. I saw an earlier version
>of this in freebsd-questions and followed up with him.
>
>I've appended the version I think he meant to include.
>
>He's reporting this behavior with 3.2R. Runs fine with 'mmap -u', appears to
>hang the machine on the se
Looks like Oleg made a mistake in posting the code. I saw an earlier version
of this in freebsd-questions and followed up with him.
I've appended the version I think he meant to include.
He's reporting this behavior with 3.2R. Runs fine with 'mmap -u', appears to
hang the machine on the second it
> >He's trying to ask if this is a problem with the code in question or 3.2R's
> >mmap.
>
>That's better. It appears to be a classic resource related deadlock that
> is caused by the VFS code needing pages in order to page things out (and thus
> free up pages), but is unable to since no memor
This report seems to be severely lacking in details. First, I don't
understand why it is called "mmap" since it doesn't do an mmap and the
"addr" that is being frobbed with isn't even initialized. Second, I
get a core dump when I run it on a -stable machine:
[speedy:tmp9] mmap
unlink files? NO
Um, just where do you call mmap(2) in this code?
- ad
Oleg Derevenetz wrote:
> This small program, running as 'mmap', not 'mmap -u', can hang my machine.
> Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
> Thank you for answer.
>
> #include
> #include
> #include
> #include
>
>Looks like Oleg made a mistake in posting the code. I saw an earlier version
>of this in freebsd-questions and followed up with him.
>
>I've appended the version I think he meant to include.
>
>He's reporting this behavior with 3.2R. Runs fine with 'mmap -u', appears to
>hang the machine on the s
Are you running this as root?
<- - - . .
Bosko Milekic http://www.dsuper.net/~bmilekic/
Network Operations - Delphi SuperNet, an Internet Direct company
+1.514.281.7500 (vox) / +1.514.281.6599 (fax) / http://www.dsuper.net/
On Wed, 11 Aug 1999 20:48:08 +0400 (MSD)
Oleg Derevenetz wrote:
> This small program, running as 'mmap', not 'mmap -u', can hang my machine.
> Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
> Thank you for answer.
If it hangs your system, must be a bug in FreeBSD. Here is
Looks like Oleg made a mistake in posting the code. I saw an earlier version
of this in freebsd-questions and followed up with him.
I've appended the version I think he meant to include.
He's reporting this behavior with 3.2R. Runs fine with 'mmap -u', appears to
hang the machine on the second i
This report seems to be severely lacking in details. First, I don't
understand why it is called "mmap" since it doesn't do an mmap and the
"addr" that is being frobbed with isn't even initialized. Second, I
get a core dump when I run it on a -stable machine:
[speedy:tmp9] mmap
unlink files? NO
Um, just where do you call mmap(2) in this code?
- ad
Oleg Derevenetz wrote:
> This small program, running as 'mmap', not 'mmap -u', can hang my machine.
> Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
> Thank you for answer.
>
> #include
> #include
> #include
> #include
>
Are you running this as root?
<- - - . .
Bosko Milekic <[EMAIL PROTECTED]> http://www.dsuper.net/~bmilekic/
Network Operations - Delphi SuperNet, an Internet Direct company
+1.514.281.7500 (vox) / +1.514.281.6599 (fax) / http://www.dsuper.net/
On Wed, 11 Aug 1999 20:48:08 +0400 (MSD)
Oleg Derevenetz <[EMAIL PROTECTED]> wrote:
> This small program, running as 'mmap', not 'mmap -u', can hang my machine.
> Is this a known bug in FreeBSD's kernel, or it is my fantasy ?
> Thank you for answer.
If it hangs your system, must be a bug
32 matches
Mail list logo
