Mike Silbersack wrote:
On Tue, 4 Nov 2003, Vivek Pai wrote:
The one other aspect of this is that sf_bufs mappings are maintained for
a configurable amount of time, reducing the number of TLB ops. You can
specify the parameter for how long, ranging from -1 (no coalescing at
all), 0 (coalesce, but
Sorry for not replying sooner - under deadline pressure right now.
Mike Silbersack wrote:
Ok, I've reread the debox paper, looked over the patch, and talked to Alan
Cox about his present and upcoming work on the vm system.
The debox patch does three basic things (if I'm understanding everything
co
David Schultz wrote:
Okay, I guess SpecWeb99 is ``real world'' enough for me to justify
the assertion that there is an mmap() performance problem. Just
out of curiosity, how many regions did SpecWeb99 map?
(i.e. what does 'dd if=/proc/$pid/map bs=64k count=1 | wc -l' give?)
The SpecWeb99 benchmark
Take a look at Figure 6, page 9 in the following:
http://www.cs.princeton.edu/~yruan/DeBox/debox.pdf
On a 1GHz box with 1GB of memory, we were spending
4-5 milliseconds per mmap call, and that was limiting
the throughput of our server on SpecWeb99.
Figure 9 on page 11 shows that just getting rid of
Before we proceed on this, I'd like to ask is there actuall a committer
ready to follow up on this? We currently make our patches available on
Ping's homepage, and they're relatively clean. He spent a fair bit of
time getting it from a relatively ugly set of changes to something more
elegant and be
There are two scenarios - sendfile can't proceed immediately because all
sfbuf space is exhausted, and sendfile can't proceed immediately because
the page to be sent isn't in physical memory.
In both cases, we can have another process/thread call sendfile with the
flag cleared, allowing sendfile to
6 matches
Mail list logo
