Skip to contentSkip to conversation

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

DISCUSSION Rik van Riel 1 participant 1 message Dec 16, 1998 1 message not in the archive Memory management

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

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

Quoted 8 lines · Jay Nordwick
Quoted 7 lines

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

Quoted 5 lines

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.        [email protected] |
| 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: [email protected]