lkml.org 
[lkml]   [1998]   [Mar]   [9]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: mmap() versus read()
DateMon, 9 Mar 1998 08:33:50 +0100 (MET)
From(Erik Corry)
In article <199803090215.CAA154158@out2.ibm.net> you wrote:
> : I just perused the solaris madvise() man page and I don't think it would
> : help apache in the long run.  Specifically:
> : 
> :      MADV_SEQUENTIAL
> :           Tells the system  that  addresses  in  this  range  are
> :           likely  to  be  accessed  only once, so the system will
> :           free the resources mapping the address range as quickly
> :           as  possible.

> If I remember correctly from my SunOS kernel hacking days, this call
> doesn't do much.

From my tests on Solaris that's still true. However the other advices
for madvise (WILLNEED and DONTNEED) are very useful indeed.

> Anyway, this call never worked very well in SunOS and I doubt they have
> fixed it in Solaris.  I'd be interested in hearing if someone can come
> up with a test program that shows different behavior with and w/o the
> madvise.

I can, if you're interested, but with the above advice constants,
not with MADV_SEQUENTIAL.

> I made the call largely redundant, in UFS, by putting in automatic
> free behind for sequential accesses.  This was a huge hack and a huge
> win.  The idea was this:

> 	. the file system eeps track of sequential access in the inode
> 	  (almost all file systems do this for read ahead).

> 	. the file system "knows" when the VM system is going to start
> 	  being starved for memory and start paging stuff out.

> 	. on large (>256K 6 years ago, probably .5M or 1M today) files

Probably dependent on RAM size.

> 	  that are being accessed sequentially, the file system looks at
> 	  free memory on each page in request, if it is close (within
> 	  about 1M or so) to being all used up, the file system looks 
> 	  backwards a "windows" worth (say .25M) and frees up the pages 
> 	  behind.  

> The effect is that memory fills up with whatever and then when large I/O
> happens, the OS just slides a .5M window through the file.  

Sounds very cool.

-- 
Erik Corry erik@arbat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 12:41    [from the cache]
©2003-2008