On Fri, 31 Oct 2003, Vivek Pai wrote:
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
On Fri, Oct 31, 2003, Vivek Pai wrote:
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.
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
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
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
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
On Sun, Oct 26, 2003, Lowell Gilbert wrote:
David Schultz [EMAIL PROTECTED] writes:
On Sun, Oct 26, 2003, Dag-Erling Smrgrav wrote:
Q [EMAIL PROTECTED] writes:
Yes, it would appear this is a legacy thing that existed in the original
1994 import of the BSD 4.4 Lite source. Both
:...
: A hash probably isn't the right data structure for either dimension
: (DES didn't say it was, I notice). Finding the next-largest available
: entry is a useful operation, here, so a list would be better than a
: hash. [Or a tree; the point is that exact-match isn't the only kind
: of
On Sat, 25 Oct 2003, David Schultz wrote:
But regardless of the approach, someone has yet to demonstrate
that this is actually a performance problem in the real world. ;-)
I could be way wrong, but I would think that a database might mmap
discontiguous segments of memory. Perhaps someone
On Sun, Oct 26, 2003, Mike Silbersack wrote:
On Sat, 25 Oct 2003, David Schultz wrote:
But regardless of the approach, someone has yet to demonstrate
that this is actually a performance problem in the real world. ;-)
I could be way wrong, but I would think that a database might mmap
David Schultz [EMAIL PROTECTED] writes:
I'm not particularly ``familiar'' with postgres, but I did some
performance tests on it a little while ago. Grepping through one
of the traces just now, I found that database system made 139
calls to mmap(), and the maximum number of regions mapped at
David Schultz [EMAIL PROTECTED] writes:
On Sun, Oct 26, 2003, Dag-Erling Smrgrav wrote:
Q [EMAIL PROTECTED] writes:
Yes, it would appear this is a legacy thing that existed in the original
1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still
use this technique, but
As always, you're seeing the lack of available committer time, not a real
lack of interest. One way to accelerate the process might be for someone
(not necessarily you, any reader of this mailing list could do it) to show
that this change visibly benefits some easy to run benchmark. Some simple
[EMAIL PROTECTED] wrote this message on Sun, Oct 26, 2003 at 10:48 -0500:
We decided to avoid all mmap/mincore operations, and opted to instead
add a flag to sendfile such that we can try sendfile and have it return
an error (instead of blocking) when a page isn't in memory.
I was thinking
On Sun, 26 Oct 2003 [EMAIL PROTECTED] wrote:
Details about what we have so far are at
http://www.cs.princeton.edu/~yruan/debox/
Yaoping Ruan had mentioned this on the list before (and sent a
pointer to the sendfile patches), but didn't seem to get much
response.
-Vivek
As always, you're
We've been trying to get good SpecWeb99 numbers on FreeBSD using a
user-space server. Our initial results weren't that impressive,
and we traced them to a number of issues, including VM system performance.
We decided to avoid all mmap/mincore operations, and opted to instead
add a flag to sendfile
Ted Unangst wrote:
On Fri, 24 Oct 2003, Michel TALON wrote:
What is more interesting is to look at the actual benchmark results in
http://bulk.fefe.de/scalability/
in particular the section about mmap benchmarks, the only one where
OpenBSD shines. However as soon as touching pages is
On Wed, Oct 22, 2003, Q wrote:
As an effort to get more acquainted with the FreeBSD kernel, I have been
looking through how mmap works. I don't yet understand how it all fits
together, or of the exact implications things may have in the wild, but
I have noticed under some synthetic conditions,
On Sat, 25 Oct 2003, Terry Lambert wrote:
Why does the benchmark need to be fixed for OpenBSD and not
for any other platform?
openbsd does not have a unified cache between file system (pread) and vm
(mmap) interfaces. in the real world, it's unusual to find an application
that uses both
Q [EMAIL PROTECTED] writes:
Yes, it would appear this is a legacy thing that existed in the original
1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still
use this technique, but OpenBSD changed to using Red-Black trees back in
Feb 2002.
[...]
I am wondering if there is a
On Sun, Oct 26, 2003, Dag-Erling Smrgrav wrote:
Q [EMAIL PROTECTED] writes:
Yes, it would appear this is a legacy thing that existed in the original
1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still
use this technique, but OpenBSD changed to using Red-Black trees back in
Yes, it would appear this is a legacy thing that existed in the original
1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still
use this technique, but OpenBSD changed to using Red-Black trees back in
Feb 2002.
What is more interesting is to look at the actual benchmark
On Fri, Oct 24, 2003 at 01:27:40PM +0200, Michel TALON wrote:
What is more interesting is to look at the actual benchmark results in
Take a look at the following paper:
Juan E. Navarro and Alan Cox. Mitosis: a high performance, scalable
virtual memory system. Technical report TTR01-378, CS
Q wrote:
Good point, maybe I should have said increasing growth instead of
linear ;)
It looked linear to me, however the constant factor was much smaller.
In the real world, that is often good enough. The Linux 2.6 kernel
looks like it has a constant time algorithm.
--
\ |_ _|__ __|_ \ __|
On Fri, 24 Oct 2003, Michel TALON wrote:
What is more interesting is to look at the actual benchmark results in
http://bulk.fefe.de/scalability/
in particular the section about mmap benchmarks, the only one where
OpenBSD shines. However as soon as touching pages is benchmarked
OpenBSD fails
On Thu, Oct 23, 2003 at 09:36:48AM +1000, Q wrote:
This is interesting, and demonstrates what I have been seeing, however
OpenBSD obviously has other issues with it's mmap implementation
entirely separate from this discussion.
Indeed, but also note the OpenBSD graph¹
is actually two graphs,
I beg to differ. It might show linear growth, but the OpenBSD graph is
definitely not O(n).
Seeya...Q
On Thu, 2003-10-23 at 21:23, Andy wrote:
On Thu, Oct 23, 2003 at 09:36:48AM +1000, Q wrote:
This is interesting, and demonstrates what I have been seeing, however
OpenBSD obviously has
On Thu, Oct 23, 2003 at 09:55:21PM +1000, Q wrote:
I beg to differ. It might show linear growth, but the OpenBSD graph is
definitely not O(n).
Err... How would you define O(n) then ?
Zlo
___
[EMAIL PROTECTED] mailing list
On Thu, Oct 23, 2003 at 09:55:21PM +1000, Q wrote:
I beg to differ. It might show linear growth, but the OpenBSD graph is
definitely not O(n).
Hmm, it looks like that when it hits the next threshold, it's O(n),
but O(1) otherwise. But contrary to the blurry Linux 2.4 fork() graph,
the
Good point, maybe I should have said increasing growth instead of
linear ;)
Seeya...Q
On Thu, 2003-10-23 at 23:02, Marc Olzheim wrote:
On Thu, Oct 23, 2003 at 09:55:21PM +1000, Q wrote:
I beg to differ. It might show linear growth, but the OpenBSD graph is
definitely not O(n).
Err...
On Wed, Oct 22, 2003 at 12:22:35PM +1000, Q wrote:
Can someone comment on whether this is something that has been done
intentionally, or avoided in favour of some other yet to be implemented
solution? Or is it still on someones todo list.
You can consult the FreeBSD and OpenBSD CVS
In message [EMAIL PROTECTED], Kris Kennaway wrote:
On Wed, Oct 22, 2003 at 12:22:35PM +1000, Q wrote:
Can someone comment on whether this is something that has been done
intentionally, or avoided in favour of some other yet to be implemented
solution? Or is it still on someones todo list.
You
On Wed, Oct 22, 2003 at 05:38:45PM +0900, User Takawata wrote:
In message [EMAIL PROTECTED], Kris Kennaway wrote:
On Wed, Oct 22, 2003 at 12:22:35PM +1000, Q wrote:
Can someone comment on whether this is something that has been done
intentionally, or avoided in favour of some other yet to
Thanks, I have already looked over the repositories to determine how
they differed. I wasn't really asking about the history of these changes
in the other projects, but rather the history of why FreeBSD HASN'T also
gone down this road. There doesn't appear to be anything in CVS or the
mail
On Wed, Oct 22, 2003 at 07:51:28PM +1000, Q wrote:
Thanks, I have already looked over the repositories to determine how
they differed. I wasn't really asking about the history of these changes
in the other projects, but rather the history of why FreeBSD HASN'T also
gone down this road. There
Yes, it would appear this is a legacy thing that existed in the original
1994 import of the BSD 4.4 Lite source. Both FreeBSD and NetBSD still
use this technique, but OpenBSD changed to using Red-Black trees back in
Feb 2002.
The actual commit quote reads:
use a red-black tree to find entries
In the last episode (Oct 22), Q said:
Yes, it would appear this is a legacy thing that existed in the
original 1994 import of the BSD 4.4 Lite source. Both FreeBSD and
NetBSD still use this technique, but OpenBSD changed to using
Red-Black trees back in Feb 2002.
The actual commit quote
On Wed, Oct 22, 2003 at 09:40:44AM -0500, Dan Nelson wrote:
The actual commit quote reads:
use a red-black tree to find entries in the vm_map. augment the
red-black tree to find free space between entries. speeds up memory
allocation, etc...
I am wondering if there is a compelling
On Wed, Oct 22, 2003 at 04:50:58PM +0100, Bruce M Simpson wrote:
On Wed, Oct 22, 2003 at 09:40:44AM -0500, Dan Nelson wrote:
The actual commit quote reads:
use a red-black tree to find entries in the vm_map. augment the
red-black tree to find free space between entries. speeds up
This is interesting, and demonstrates what I have been seeing, however
OpenBSD obviously has other issues with it's mmap implementation
entirely separate from this discussion.
The case we are discussing is only about the choice of search technique
used during the allocation of the mmap region
40 matches
Mail list logo
