linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>
To: "Eric W. Biederman" <ebiederm+eric@npwt.net>
Cc: linux-kernel@vger.rutgers.edu, linux-mm@kvack.org
Subject: Re: Thread implementations...
Date: Thu, 25 Jun 1998 09:41:18 +1000	[thread overview]
Message-ID: <199806242341.JAA15101@vindaloo.atnf.CSIRO.AU> (raw)
In-Reply-To: <m1u35a4fz8.fsf@flinx.npwt.net>

Eric W. Biederman writes:
> >>>>> "RG" == Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> writes:
> 
> RG> If we get madvise(2) right, we don't need sendfile(2), correct?
> 
> It looks like it from here.  As far as madvise goes, I think we need
> to implement madvise(2) as:
> 
> enum madvise_strategy {
>         MADV_NORMAL,
>         MADV_RANDOM,
>         MADV_SEQUENTIAL,
>         MADV_WILLNEED,
>         MADV_DONTNEED,
> }
> struct madvise_struct {
> 	caddr_t addr;
> 	size_t size;
> 	size_t strategy;
> };
> int sys_madvise(struct madvise_struct *, int count);
> 
> With madvise(3) following the traditional format with only one
               ^
Don't you mean 2?

> advisement can be done easily.  The reason I suggest multiple
> arguments is that for apps that have random but predictable access
> patterns will want to use MADV_WILLNEED & MADV_DONTNEED to an optimum
> swapping algorigthm.

I'm not aware of madvise() being a POSIX standard. I've appended the
man page from alpha_OSF1, which looks reasonable. It would be nice to
be compatible with something.

				Regards,

					Richard....
===============================================================================
madvise(2)							   madvise(2)



NAME

  m\bma\bad\bdv\bvi\bis\bse\be - Advise the system of the expected paging behavior of a process

SYNOPSIS

  #\b#i\bin\bnc\bcl\blu\bud\bde\be <\b<s\bsy\bys\bs/\b/t\bty\byp\bpe\bes\bs.\b.h\bh>\b>
  #\b#i\bin\bnc\bcl\blu\bud\bde\be <\b<s\bsy\bys\bs/\b/m\bmm\bma\ban\bn.\b.h\bh>\b>
  i\bin\bnt\bt m\bma\bad\bdv\bvi\bis\bse\be (\b(
	  c\bca\bad\bdd\bdr\br_\b_t\bt _\ba_\bd_\bd_\br,\b,
	  s\bsi\biz\bze\be_\b_t\bt _\bl_\be_\bn,\b,
	  i\bin\bnt\bt _\bb_\be_\bh_\ba_\bv )\b);\b;

PARAMETERS

  _\ba_\bd_\bd_\br	    Specifies the address of the region	to which the advice refers.

  _\bl_\be_\bn	    Specifies the length in bytes of the region	specified by the _\ba_\bd_\bd_\br
	    parameter.

  _\bb_\be_\bh_\ba_\bv	    Specifies the behavior of the region.  The following values	for
	    the	_\bb_\be_\bh_\ba_\bv parameter	are defined in the s\bsy\bys\bs/\b/m\bmm\bma\ban\bn.\b.h\bh header file:

	    M\bMA\bAD\bDV\bV_\b_N\bNO\bOR\bRM\bMA\bAL\bL
		      No further special treatment

	    M\bMA\bAD\bDV\bV_\b_R\bRA\bAN\bND\bDO\bOM\bM
		      Expect random page references

	    M\bMA\bAD\bDV\bV_\b_S\bSE\bEQ\bQU\bUE\bEN\bNT\bTI\bIA\bAL\bL
		      Expect sequential	references

	    M\bMA\bAD\bDV\bV_\b_W\bWI\bIL\bLL\bLN\bNE\bEE\bED\bD
		      Will need	these pages

	    M\bMA\bAD\bDV\bV_\b_D\bDO\bON\bNT\bTN\bNE\bEE\bED\bD
		      Do not need these	pages

		      The system will free any resident	pages that are allo-
		      cated to the region.  All	modifications will be lost
		      and any swapped out pages	will be	discarded.  Subse-
		      quent access to the region will result in	a zero-fill-
		      on-demand	fault as though	it is being accessed for the
		      first time.  Reserved swap space is not affected by
		      this call.

	    M\bMA\bAD\bDV\bV_\b_S\bSP\bPA\bAC\bCE\bEA\bAV\bVA\bAI\bIL\bL
		      Ensure that resources are	reserved

DESCRIPTION

  The m\bma\bad\bdv\bvi\bis\bse\be(\b()\b)	function permits a process to advise the system	about its
  expected future behavior in referencing a mapped file	or shared memory
  region.

NOTES

  Only a few values of the b\bbe\beh\bha\bav\bv parameter values are operational on Digital
  UNIX systems.	 Non-operational values	cause the system to always return
  success (zero).

RETURN VALUES

  Upon successful completion, the m\bma\bad\bdv\bvi\bis\bse\be(\b()\b) function returns zero.  Other-
  wise,	-1 is returned and e\ber\brr\brn\bno\bo is set	to indicate the	error.

ERRORS

  If the m\bma\bad\bdv\bvi\bis\bse\be(\b()\b) function fails, e\ber\brr\brn\bno\bo may be	set to one of the following
  values:

  [\b[E\bEI\bIN\bNV\bVA\bAL\bL]\b]  The	_\bb_\be_\bh_\ba_\bv parameter	is invalid.

  [\b[E\bEN\bNO\bOS\bSP\bPC\bC]\b]  The	_\bb_\be_\bh_\ba_\bv parameter	specifies MADV_SPACEAVAIL and resources	can
	    not	be reserved.

RELATED	INFORMATION

  Functions: m\bmm\bma\bap\bp(2)

  reply	other threads:[~1998-06-24 23:41 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 [this message]
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
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=199806242341.JAA15101@vindaloo.atnf.CSIRO.AU \
    --to=richard.gooch@atnf.csiro.au \
    --cc=ebiederm+eric@npwt.net \
    --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