:Why? I can think of at least one instance where this is useful: using
:a file in the file system as a shared memory handle.
:
:Seems as if the programmer erroneously MADV_FREE's a file, well ... you
:only supplied the rope.
:
:-- Jason R. Thorpe
My main worry here, putting it into
On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
Matthew Dillon wrote:
> Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects.
> We do not do this for file objects... it would make me rather nervous
> if we did :-)
Why? I can think of at least one instance where thi
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon wrote:
> Shoot, it barely took 10 minutes for me to move the behavior field from
> the object to the vm map entry.
...make sure the map entries are clipped properly. It's easy to miss this
in the most common test case of advisi
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon wrote:
> I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to
> make them work on files in a reasonable way).
When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):
DONTNEED: deactivate page
On Fri, 30 Jul 1999 01:50:28 +0900
"Daniel C. Sobral" wrote:
> Could you please elaborate on "permanent"? To what structure the
> information is currently attached, and what, if anything, can make
> that structure "go away", short of a reboot?
As permanent as the object ... i.e. as long as
On Thu, 29 Jul 1999 09:26:12 -0700 (PDT)
Matthew Dillon wrote:
> Yes, it will work. Oops. I do see one problem though... if you do
> this the underlying file object will be marked for sequential operation
> even after the grep (in this case) exits. That is, an madvise() of
>
:On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
: Matthew Dillon wrote:
:
: > Shoot, it barely took 10 minutes for me to move the behavior field from
: > the object to the vm map entry.
:
:...make sure the map entries are clipped properly. It's easy to miss this
:in the most common test case o
:Why? I can think of at least one instance where this is useful: using
:a file in the file system as a shared memory handle.
:
:Seems as if the programmer erroneously MADV_FREE's a file, well ... you
:only supplied the rope.
:
:-- Jason R. Thorpe <[EMAIL PROTECTED]>
My main worry he
:
:On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
: Matthew Dillon wrote:
:
: > Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP
objects.
: > We do not do this for file objects... it would make me rather nervous
: > if we did :-)
:
:Why? I can think of at least one instan
On Thu, 29 Jul 1999 09:26:12 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Yes, it will work. Oops. I do see one problem though... if you do
> this the underlying file object will be marked for sequential operation
> even after the grep (in this case) exits. That is,
On Fri, 30 Jul 1999 01:50:28 +0900
"Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
> Could you please elaborate on "permanent"? To what structure the
> information is currently attached, and what, if anything, can make
> that structure "go away", short of a reboot?
As permanent as the object
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to
> make them work on files in a reasonable way).
When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):
DONTN
On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Shoot, it barely took 10 minutes for me to move the behavior field from
> the object to the vm map entry.
...make sure the map entries are clipped properly. It's easy to miss this
in the most common
On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
Matthew Dillon <[EMAIL PROTECTED]> wrote:
> Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects.
> We do not do this for file objects... it would make me rather nervous
> if we did :-)
Why? I can think of at least on
:When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):
:
: DONTNEED: deactivate pages
There are some medium sized problems with doing this under FreeBSD, mainly
that this will cause the pages to recycle through the inactive and cache
queues. Without anything to bump
Shoot, it barely took 10 minutes for me to move the behavior field from
the object to the vm map entry.
I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to
make them work on files in a reasonable way).
This will be current-only, though I suppose the map ch
:On Thu, 29 Jul 1999 10:21:52 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > Shoot, it barely took 10 minutes for me to move the behavior field from
: > the object to the vm map entry.
:
:...make sure the map entries are clipped properly. It's easy to miss this
:in the mos
:
:On Thu, 29 Jul 1999 10:52:02 -0700 (PDT)
: Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
: > Yes, we already do this, but only for OBJT_DEFAULT and OBJT_SWAP objects.
: > We do not do this for file objects... it would make me rather nervous
: > if we did :-)
:
:Why? I can think of
:On Fri, 30 Jul 1999 01:50:28 +0900
: "Daniel C. Sobral" wrote:
:
: > Could you please elaborate on "permanent"? To what structure the
: > information is currently attached, and what, if anything, can make
: > that structure "go away", short of a reboot?
:
:As permanent as the object ... i.e. as
:When I implemented MADV_DONTNEED and MADV_FREE in NetBSD (UVM):
:
: DONTNEED: deactivate pages
There are some medium sized problems with doing this under FreeBSD, mainly
that this will cause the pages to recycle through the inactive and cache
queues. Without anything to bum
Matthew Dillon wrote:
>
> Yes, it will work. Oops. I do see one problem though... if you do
> this the underlying file object will be marked for sequential operation
> even after the grep (in this case) exits. That is, an madvise() of
> MADV_NORMAL, SEQUENTIAL, or RANDOM appears
Shoot, it barely took 10 minutes for me to move the behavior field from
the object to the vm map entry.
I'm testing it now along with the madvise(... MADV_DONTNEED) changes (to
make them work on files in a reasonable way).
This will be current-only, though I suppose the map c
:So it works, then? GNU grep has this #ifdef'ed out, with a comment
:about it impacting negatively on performance on BSD 4.1. I recall
:some rants on this subject a couple of years ago... If it is
:working, I'd like to change that 0 to 1 in our tree.
:
:--
:Daniel C. Sobral (
:On Fri, 30 Jul 1999 01:50:28 +0900
: "Daniel C. Sobral" <[EMAIL PROTECTED]> wrote:
:
: > Could you please elaborate on "permanent"? To what structure the
: > information is currently attached, and what, if anything, can make
: > that structure "go away", short of a reboot?
:
:As permanent as th
Matthew Dillon wrote:
>
> Yes, it will work. Oops. I do see one problem though... if you do
> this the underlying file object will be marked for sequential operation
> even after the grep (in this case) exits. That is, an madvise() of
> MADV_NORMAL, SEQUENTIAL, or RANDOM appear
:So it works, then? GNU grep has this #ifdef'ed out, with a comment
:about it impacting negatively on performance on BSD 4.1. I recall
:some rants on this subject a couple of years ago... If it is
:working, I'd like to change that 0 to 1 in our tree.
:
:--
:Daniel C. Sobral
26 matches
Mail list logo
