Re: mmap() is slower than read() on SCSI/IDE on 2.0 and 2.1

Re: mmap() is slower than read() on SCSI/IDE on 2.0 and 2.1

[Rogier Wolff]

Marc Lehmann wrote:
> On Thu, Dec 17, 1998 at 06:52:50AM +0000, Linus Torvalds wrote:
> > Umm, the easiest hint is probably to just look at the faulting address. 
> > We have it available, after all. 
> > 
> > I suspect that such a simple heuristic would be fairly accurate, and it
> > can be coupled with other heuristics to further increase the accuracy. 
> 
> file copy, yes. But grep (and probably lots of others) don't access memory
> sequentially (as faster search algorithms exist)

A fast search algorithm, touches memory every n bytes where n is the
size of the largest constant string that you're searching for. 

That way "n" is typically small, so that you end up hitting the first
n bytes pretty often.

If you're acessing 

	struct blabla {
        int ...
	float ...
	char [];
	}

mmapped from a file, you might be looking for a certain float. As long
as you're doing a linear search, you'll again hit the first few bytes
of a page pretty often.


				Roger.

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
*   Never blow in a cat's ear because if you do, usually after three or  *
*   four times, they will bite your lips!  And they don't let go for at  *
*   least a minute. -- Lisa Coburn, age 9

-
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/

Re: mmap() is slower than read() on SCSI/IDE on 2.0 and 2.1

[Rik van Riel]

(CC:d to Linux-MM to have the last paragraph on record)

On Tue, 15 Dec 1998, Jay Nordwick wrote:

> >And it's not needed at all. We can see if the program is
> >doing sequential reading by simply testing for the presence
> >of pages in the proximity of the faulting address. If there
> >are a lot of pages present behind the current address then
> >we should do read-ahead. With pages in front of us we want
> >read-behind and with no pages or an 'equal' distribution
> >we want a little bit of both read-ahead and read-behind...
> 
> It is needed for hints that you cannot give any other way
> (such as MADV_FREE, MADV_WILLNEED, MADV_DONTNEED).  But as
> the discussion progesses I do see less and less of a need.  I
> can see how it can be called a hack as a VM systems that
> learns from page fault histories better can obviate it.

Since we don't really use page aging anymore, the FREE, WILLNEED
and DONTNEED won't make that much of an impact on performance.

I'm sure they can actually make 25% difference in some borderline
cases, but in RL it'll be pretty marginal -- so marginal that we
don't want the extra code in the kernel...

All the pretty code is better spent on very very good readahead/
readbehind algorithms -- memory is plentyful, disk throughput is
great. We don't have the serious memory shortages that plagued
every system 5 or 10 years ago -- today disk seek time is our big
enemy...

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org