On Tuesday 22 June 2004 11:27 pm, Peter Wemm wrote:
= mmap is more valuable as a programmer convenience these days. Don't
= make the mistake of assuming its faster, especially since the cost of
= a copy has gone way down.
Actually, let me back off from agreeing with you here :-) On io-bound
machi
вівторок 22 червень 2004 23:27, Peter Wemm, Ви написали:
= On Monday 21 June 2004 10:08 pm, Mikhail Teterin wrote:
= The amount of "work" for the kernel to do a read() and a high-speed
= memory copy is much less than the cost of taking a page fault, running
= a whole bunch of really really nasty c
On Monday 21 June 2004 10:08 pm, Mikhail Teterin wrote:
> On Monday 21 June 2004 08:15 pm, Matthew Dillon wrote:
>
> = :The mmap interface is supposed to be more efficient -- theoreticly
> = :-- because it requires one less buffer-copying, and because it
> = :(together with the possible madvise())
(current removed, but I'm leaving this on question@ since it contains
some useful information).
:This is, sort of, self-perpetuating -- as long as mmap is slower/less
:reliable, applications will be hesitant to use it, thus there will be
:little insentive to improve it. :-(
Well, agai
On Monday 21 June 2004 08:15 pm, Matthew Dillon wrote:
= :The mmap interface is supposed to be more efficient -- theoreticly
= :-- because it requires one less buffer-copying, and because it
= :(together with the possible madvise()) provides the kernel with more
= :information thus enabling it to
Matthew Dillon wrote:
Mikhail Teterin wrote:
=Both read and mmap have a read-ahead heuristic. The heuristic
=works. In fact, the mmap heuristic is so smart it can read-behind
=as well as read-ahead if it detects a backwards scan.
Evidently, read's heuristics are better. At least, for th
:The mmap interface is supposed to be more efficient -- theoreticly --
:because it requires one less buffer-copying, and because it (together
:with the possible madvise()) provides the kernel with more information
:thus enabling it to make better (at least -- no worse) decisions.
Well, I thin
:
:ask for 8k, but the system will fetch the next 64k of data. Problem is
:the system does nothing until you read the next 8k past the 64k
:alreqady read in, then it jumps up and grabs the next 64k. You're
:still waiting on I/O every 8th read. Ideally it would do an async
:..
:--
: Dan N
In the last episode (Jun 21), Mikhail Teterin said:
> > Both read and mmap have a read-ahead heuristic. The heuristic
> > works. In fact, the mmap heuristic is so smart it can read-behind
> > as well as read-ahead if it detects a backwards scan.
>
> Evidently, read's heuristics are better. At leas
=Both read and mmap have a read-ahead heuristic. The heuristic
=works. In fact, the mmap heuristic is so smart it can read-behind
=as well as read-ahead if it detects a backwards scan.
Evidently, read's heuristics are better. At least, for this task. I'm,
actually, surprised, they are
:
:= pre-faulting is best done by a worker thread or child process, or it
:= will just slow you down..
:
:Read is also used for large files sometimes, and never tries to prefetch
:the whole file at once. Why can't the same smarts/heuristics be employed
:by the page-fault handling code -- especiall
On Sunday 20 June 2004 08:16 pm, Julian Elischer wrote:
= On Sun, 20 Jun 2004, Matthew Dillon wrote:
[...]
= > It is usually a bad idea to try to populate the page table with
= > all resident pages associated with the a memory mapping, because
= > mmap() is often used to map huge files.
On Sun, 20 Jun 2004, Matthew Dillon wrote:
> Hmm. Well, you can try calling madvise(... MADV_WILLNEED), that's what
> it is for.
>
> It is usually a bad idea to try to populate the page table with all
> resident pages associated with the a memory mapping, because mmap()
>
Hmm. Well, you can try calling madvise(... MADV_WILLNEED), that's what
it is for.
It is usually a bad idea to try to populate the page table with all
resident pages associated with the a memory mapping, because mmap()
is often used to map huge files... hundreds of megabytes
On Sunday 20 June 2004 02:35 pm, you wrote:
=
= :I this how things are supposed to be, or will mmap() become more
= :efficient eventually? Thanks!
= :
= : -mi
= It's hard to say. mmap() could certainly be made more efficient, e.g.
= by faulting in more pages at a time to reduce the ac
:Hello!
:
:I'm writing a message-digest utility, which operates on file and
:can use either stdio:
:
: while (not eof) {
: char buffer[BUFSIZE];
: size = read( buffer ...);
: process(buffer, size);
: }
:
:or mmap:
:
: buffer = mmap(...
On Sunday 20 June 2004 11:41 am, Dan Nelson wrote:
= In the last episode (Jun 20), Mikhail Teterin said:
= > I expected the second way to be faster, as it is supposed to avoid
= > one memory copying (no user-space buffer). But in reality, on a
= > CPU-bound (rather than IO-bound) machine, using mma
In the last episode (Jun 20), Mikhail Teterin said:
> I expected the second way to be faster, as it is supposed to avoid
> one memory copying (no user-space buffer). But in reality, on a
> CPU-bound (rather than IO-bound) machine, using mmap() is
> considerably slower. Here are the tcsh's time resu
Hello!
I'm writing a message-digest utility, which operates on file and
can use either stdio:
while (not eof) {
char buffer[BUFSIZE];
size = read( buffer ...);
process(buffer, size);
}
or mmap:
buffer = mmap(... file_si
19 matches
Mail list logo
