linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
To: "Eric W. Biederman" <ebiederm+eric@npwt.net>
Cc: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>,
	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 14:10:52 +0100	[thread overview]
Message-ID: <199806301310.OAA00911@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <m1vhpj8l95.fsf@flinx.npwt.net>

Hi,

On 30 Jun 1998 01:19:18 -0500, ebiederm+eric@npwt.net (Eric
W. Biederman) said:

> Again the case was: I have a multithreaded web server serving up
> files.  The web server mmaps each file, and calls madvise(file_start,
> file_len, MADV_SEQUENTIAL).  The trick is that it may be serving the
> say file to two different clients simultaneously.

The actual sharing is not a problem; the cache is already safe against
that even when doing readahead.

> MADV_SEQUENTIAL implies readahead, and forget behind, but for a simple
> process.

Yep, the forget behind is the important stuff to get right, but all we
need to do there is to unmap the pages from the process's address space:
we don't need to actually flush the page cache.  As long as the page
cache can find these pages quickly if it needs to reuse the memory for
something else, then there's no reason to actually forget the data there
and then.

> The forget behind is tricky and difficult to get right, but if we
> concentrate on aggressive readahead (in this  we will probably be
> o.k.)

Not for very large files: the forget-behind is absolutely critical in
that case.

--Stephen

  reply	other threads:[~1998-06-30 19:10 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 [this message]
1998-06-30 19:35                     ` Dean Gaudet
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=199806301310.OAA00911@dax.dcs.ed.ac.uk \
    --to=sct@dcs.ed.ac.uk \
    --cc=ebiederm+eric@npwt.net \
    --cc=hans-christoph.rohland@sap-ag.de \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    /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