From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
To: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
Cc: "Eric W. Biederman" <ebiederm+eric@npwt.net>,
Christoph Rohland <hans-christoph.rohland@sap-ag.de>,
linux-kernel@vger.rutgers.edu, linux-mm@kvack.org
Subject: Re: Thread implementations...
Date: Tue, 30 Jun 1998 12:35:35 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.3.96dg4.980630122740.23907D-100000@twinlark.arctic.org> (raw)
In-Reply-To: <199806301310.OAA00911@dax.dcs.ed.ac.uk>
On Tue, 30 Jun 1998, Stephen C. Tweedie wrote:
> Not for very large files: the forget-behind is absolutely critical in
> that case.
I dunno why you're thinking of unmapping pages though... isn't an mmap
cache the best way to amortize the extra cost of mmap()ing? In that case
you don't want the forget-behind pages to be unmapped. But you do want
them to be dropped from memory when appropriate.
Another thought re: sendfile. The network layer could hint to sendfile as
to the speed of the socket it's delivering to. With that hint and some
suitable queueing theory someone should be able to get a nifty little
algorithm that will "synchronize" sockets as much as possible without
noticeable delays to the user. By "synchronize" I mean getting them going
from the same, or nearby pages. That way on larger than memory data sets
the kernel can sacrifice some latency on a few connections in order to
improve the total throughput.
I won't pretend to have a good heuristic for it ;)
applications: multimedia servers -- audio/video streaming. These boxes
can be limited by disk bandwidth because their data sets are typically
much larger than RAM.
Dean
next prev parent reply other threads:[~1998-06-30 19:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199806240915.TAA09504@vindaloo.atnf.CSIRO.AU>
[not found] ` <Pine.LNX.3.96dg4.980624025515.26983E-100000@twinlark.arctic.org>
[not found] ` <199806241213.WAA10661@vindaloo.atnf.CSIRO.AU>
1998-06-24 22:00 ` Eric W. Biederman
1998-06-24 23:41 ` Richard Gooch
1998-06-25 4:45 ` Eric W. Biederman
1998-06-25 17:14 ` Todd Larason
1998-06-26 7:53 ` Christoph Rohland
1998-06-26 14:16 ` Eric W. Biederman
1998-06-29 10:19 ` Stephen C. Tweedie
1998-06-30 6:19 ` Eric W. Biederman
1998-06-30 13:10 ` Stephen C. Tweedie
1998-06-30 19:35 ` Dean Gaudet [this message]
1998-07-01 9:09 ` Stephen C. Tweedie
1998-06-25 4:12 ` Dean Gaudet
1998-06-25 3:53 ` Richard Gooch
1998-06-25 11:32 ` Stephen C. Tweedie
1998-06-25 21:24 ` Chris Wedgwood
1998-06-25 22:16 ` Richard Gooch
1998-06-25 4:56 ` Eric W. Biederman
1998-06-25 11:35 ` Stephen C. Tweedie
1998-06-25 20:31 ` Dean Gaudet
1998-06-30 6:40 ` Eric W. Biederman
1998-06-30 19:30 Larry McVoy
1998-07-01 8:50 ` Stephen C. Tweedie
1998-07-03 15:21 ` Rik van Riel
1998-07-03 20:05 ` Stephen C. Tweedie
1998-07-03 20:36 ` Rik van Riel
1998-07-04 16:37 ` Stephen C. Tweedie
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=Pine.LNX.3.96dg4.980630122740.23907D-100000@twinlark.arctic.org \
--to=dgaudet-list-linux-kernel@arctic.org \
--cc=ebiederm+eric@npwt.net \
--cc=hans-christoph.rohland@sap-ag.de \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=sct@dcs.ed.ac.uk \
/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