madvise(ptr, len, MADV_SEQUENTIAL)

[Jason Rutherglen]

Alan,

Do you think something like FileDescriptor.setAdvise (mirroring
posix_fadvise) makes sense?

-J

On Tue, Jun 16, 2009 at 7:21 AM, Michael McCandless <
lucene at mikemccandless.com> wrote:

> Lucene could really make use of this method.  When a segment merge
> takes place, we can read & write many GB of data, which without
> madvise on many OSs would effectively flush the IO cache (thus hurting
> our search performance).
>
> Mike
>
> On Mon, Jun 15, 2009 at 6:01 PM, Jason
> Rutherglen<jason.rutherglen at gmail.com> wrote:
> > Thanks Alan.
> >
> > I cross posted this to the Lucene dev list where we are discussing using
> > madvise for minimizing unnecessary IO cache usage when merging segments
> > (where we really want the newly merged segments in the IO cache rather
> than
> > the old segment files).
> >
> > How would the advise method work?  Would there need to be a hint in the
> > FileChannel.map method?
> >
> > -J
> >
> > On Mon, Jun 15, 2009 at 12:36 AM, Alan Bateman <Alan.Bateman at sun.com>
> wrote:
> >>
> >> Jason Rutherglen wrote:
> >>>
> >>> Is there going to be a way to do this in the new Java IO APIs?
> >>
> >> Good question, as it has come up a few times and is needed for some
> >> important use-cases. A while back I looked into adding a
> >> MappedByteBuffer#advise method to allow the application provide hints on
> the
> >> expected usage but didn't complete it. We should probably look at this
> again
> >> for jdk7.
> >>
> >> -Alan.
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe at lucene.apache.org
> For additional commands, e-mail: java-dev-help at lucene.apache.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090616/280950c8/attachment.html