This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Apr 25 01:37:18 2024 Received: from entropy.muc.muohio.edu (entropy.muc.muohio.edu [134.53.213.10]) by herbie.ucs.indiana.edu (8.8.8/8.8.8) with ESMTP id TAA12340 for ; Wed, 24 Jun 1998 19:03:40 -0500 (EST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by entropy.muc.muohio.edu (8.8.7/8.8.7) with ESMTP id TAA27966; Wed, 24 Jun 1998 19:57:49 -0400 Received: by vger.rutgers.edu id <971737-22453>; Wed, 24 Jun 1998 19:24:42 -0400 Received: from crux.tip.CSIRO.AU ([130.155.194.32]:4981 "EHLO crux.tip.CSIRO.AU" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <971750-22453>; Wed, 24 Jun 1998 19:15:18 -0400 Received: from vindaloo.atnf.CSIRO.AU (vindaloo.atnf.CSIRO.AU [130.155.198.47]) by crux.tip.CSIRO.AU (8.9.0.Beta5/8.9.0.Beta5/TIPAT-1.0b) with ESMTP id JAA18953; Thu, 25 Jun 1998 09:41:20 +1000 (EST) Received: (from rgooch@localhost) by vindaloo.atnf.CSIRO.AU (8.6.12/8.6.12) id JAA15101; Thu, 25 Jun 1998 09:41:18 +1000 Date: Thu, 25 Jun 1998 09:41:18 +1000 Message-Id: <199806242341.JAA15101@vindaloo.atnf.CSIRO.AU> From: Richard Gooch To: ebiederm+eric@npwt.net (Eric W. Biederman) Cc: linux-kernel@vger.rutgers.edu, Subject: Re: Thread implementations... In-Reply-To: References: <199806240915.TAA09504@vindaloo.atnf.CSIRO.AU> <199806241213.WAA10661@vindaloo.atnf.CSIRO.AU> Notfrom: spamlog@atnf.csiro.au X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu 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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu