From: Matt Dillon <dillon@earth.backplane.com>
To: Alfred Perlstein <bright@rush.net>
Cc: Rik van Riel <riel@conectiva.com.br>,
Charles Randall <crandall@matchlogic.com>,
Roger Larsson <roger.larsson@norran.net>,
arch@FreeBSD.ORG, linux-mm@kvack.org, sfkaplan@cs.amherst.edu
Subject: Re: on load control / process swapping
Date: Wed, 16 May 2001 11:01:24 -0700 (PDT) [thread overview]
Message-ID: <200105161801.f4GI1Oc73283@earth.backplane.com> (raw)
In-Reply-To: <20010516135707.H12365@superconductor.rush.net>
:Both of you guys are missing the point.
:
:The directio interface is meant to reduce the stress of a large
:seqential operation on a file where caching is of no use.
:
:Even if you depress the worthyness of the pages you've still
:blown rather large amounts of unrelated data out of the cache
:in order to allocate new cacheable pages.
:
:A simple solution would involve passing along flags such that if
:the IO occurs to a non-previously-cached page the buf/page is
:immediately placed on the free list upon completion. That way the
:next IO can pull the now useless bufferspace from the freelist.
:
:Basically you add another buffer queue for "throw away" data that
:exists as a "barely cached" queue. This way your normal data
:doesn't compete on the LRU with non-cached data.
:
:As a hack one it looks like one could use the QUEUE_EMPTYKVA
:buffer queue under FreeBSD for this, however I think one might
:loose the minimal amount of caching that could be done.
:
:If the direct IO happens to a page that's previously cached
:you adhere to the previous behavior.
:
:A more fancy approach might map in user pages into the kernel to
:do the IO directly, however on large MP this may cause pain because
:the vm may need to issue ipi to invalidate tlb entries.
:
:It's quite simple in theory, the hard part is the code.
:
:-Alfred Perlstein
I think someone tried to implement O_DIRECT a while back, but it
was fairly complex to try to do away with caching entirely.
I think our best bet to 'start' an implementation of O_DIRECT is
to support the flag in open() and fcntl(), and have it simply
modify the sequential detection heuristic to throw away pages
and buffers rather then simply depressing their priority.
Eventually we can implement the direct-I/O piece of the equation.
I could do this first part in an hour, I think. When I get home....
-Matt
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-05-16 18:01 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-16 15:17 Charles Randall
2001-05-16 17:14 ` Matt Dillon
2001-05-16 17:41 ` Rik van Riel
2001-05-16 17:54 ` Matt Dillon
2001-05-16 19:59 ` Rik van Riel
2001-05-16 20:41 ` Matt Dillon
2001-05-18 5:58 ` Terry Lambert
2001-05-18 6:20 ` Matt Dillon
2001-05-18 10:00 ` Andrew Reilly
2001-05-18 13:49 ` Jonathan Morton
2001-05-19 2:18 ` Rik van Riel
2001-05-19 2:56 ` Jonathan Morton
2001-05-16 17:57 ` Alfred Perlstein
2001-05-16 18:01 ` Matt Dillon [this message]
2001-05-16 18:10 ` Alfred Perlstein
[not found] <OF5A705983.9566DA96-ON86256A50.00630512@hou.us.ray.com>
2001-05-18 20:13 ` Jonathan Morton
-- strict thread matches above, loose matches on Subject: below --
2001-05-07 21:16 Rik van Riel
2001-05-07 22:50 ` Matt Dillon
2001-05-07 23:35 ` Rik van Riel
2001-05-08 0:56 ` Matt Dillon
2001-05-12 14:23 ` Rik van Riel
2001-05-12 17:21 ` Matt Dillon
2001-05-12 21:17 ` Rik van Riel
2001-05-12 23:58 ` Matt Dillon
2001-05-13 17:22 ` Rik van Riel
2001-05-15 6:38 ` Terry Lambert
2001-05-15 13:39 ` Cy Schubert - ITSD Open Systems Group
2001-05-15 15:31 ` Rik van Riel
2001-05-15 17:24 ` Matt Dillon
2001-05-15 23:55 ` Roger Larsson
2001-05-16 0:16 ` Matt Dillon
2001-05-16 8:23 ` Terry Lambert
2001-05-16 17:26 ` Matt Dillon
2001-05-08 20:52 ` Kirk McKusick
2001-05-09 0:18 ` Matt Dillon
2001-05-09 2:07 ` Peter Jeremy
2001-05-09 19:41 ` Matt Dillon
2001-05-12 14:28 ` Rik van Riel
2001-05-08 12:25 ` Scott F. Kaplan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200105161801.f4GI1Oc73283@earth.backplane.com \
--to=dillon@earth.backplane.com \
--cc=arch@FreeBSD.ORG \
--cc=bright@rush.net \
--cc=crandall@matchlogic.com \
--cc=linux-mm@kvack.org \
--cc=riel@conectiva.com.br \
--cc=roger.larsson@norran.net \
--cc=sfkaplan@cs.amherst.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox