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)
next prev parent 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