lkml.org 
[lkml]   [1999]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: mmap() better than read() fro streaming, Was: Re: Streaming disk I/O kills file buffering and makes Linux unusable
Date
On Wed, 25 Aug 1999, Alan Cox wrote:
> > > ptr=mmap(blah)
> > > mlock(ptr, ...)
> > > munmap(ptr, len)
> >
> > will mlock() automatically cause all pages to be read from the file ?
> > (I don't think)
>
> > But since I already do an mlockall() at the beginnig, there is no need of
> > additional mlock()s
>
> >From man mlock
>
> All pages which contain a
> part of the specified memory range are guaranteed be resi-
> dent in RAM when the mlock system call returns success-
> fully and they are guaranteed to stay in RAM until the
> pages are unlocked by munlock or munlockall

nice, so I can avoid referencing the mmap()ed region in steps of 4096 bytes.

in your suggested solution:
ptr=mmap(blah)
mlock(ptr, ...)
munmap(ptr, len)

can I avoid an munlock(ptr,...) call after mmap()ed buffer is no longer needed,
will mmap() re-utilize that region on the next call, or could this avoiding of
munlock() cause the kernel to get short of free pages ?
( Just a paranoid idea :-) )

But as stated in man munmap :
---
The munmap system call deletes the mappings for the speci-
fied address range, and causes further references to
addresses within the range to generate invalid memory ref-
erences.
---
I guess since the page does not longer exist , there is no reason to
keep the page locked into mem.

regards,
Benno.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.038 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site