From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from crux.tip.CSIRO.AU (crux.tip.CSIRO.AU [130.155.194.32]) by kvack.org (8.8.7/8.8.7) with ESMTP id TAA17115 for ; Wed, 24 Jun 1998 19:41:36 -0400 Date: Thu, 25 Jun 1998 09:41:18 +1000 Message-Id: <199806242341.JAA15101@vindaloo.atnf.CSIRO.AU> From: Richard Gooch Subject: Re: Thread implementations... In-Reply-To: References: <199806240915.TAA09504@vindaloo.atnf.CSIRO.AU> <199806241213.WAA10661@vindaloo.atnf.CSIRO.AU> Sender: owner-linux-mm@kvack.org To: "Eric W. Biederman" Cc: linux-kernel@vger.rutgers.edu, linux-mm@kvack.org List-ID: Eric W. Biederman writes: > >>>>> "RG" == Richard Gooch 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 mmaaddvviissee - Advise the system of the expected paging behavior of a process SYNOPSIS ##iinncclluuddee <> ##iinncclluuddee <> iinntt mmaaddvviissee (( ccaaddddrr__tt _a_d_d_r,, ssiizzee__tt _l_e_n,, iinntt _b_e_h_a_v ));; PARAMETERS _a_d_d_r Specifies the address of the region to which the advice refers. _l_e_n Specifies the length in bytes of the region specified by the _a_d_d_r parameter. _b_e_h_a_v Specifies the behavior of the region. The following values for the _b_e_h_a_v parameter are defined in the ssyyss//mmmmaann..hh header file: MMAADDVV__NNOORRMMAALL No further special treatment MMAADDVV__RRAANNDDOOMM Expect random page references MMAADDVV__SSEEQQUUEENNTTIIAALL Expect sequential references MMAADDVV__WWIILLLLNNEEEEDD Will need these pages MMAADDVV__DDOONNTTNNEEEEDD 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. MMAADDVV__SSPPAACCEEAAVVAAIILL Ensure that resources are reserved DESCRIPTION The mmaaddvviissee(()) 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 bbeehhaavv 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 mmaaddvviissee(()) function returns zero. Other- wise, -1 is returned and eerrrrnnoo is set to indicate the error. ERRORS If the mmaaddvviissee(()) function fails, eerrrrnnoo may be set to one of the following values: [[EEIINNVVAALL]] The _b_e_h_a_v parameter is invalid. [[EENNOOSSPPCC]] The _b_e_h_a_v parameter specifies MADV_SPACEAVAIL and resources can not be reserved. RELATED INFORMATION Functions: mmmmaapp(2)