On Tuesday 24 January 2006 17:50, Dave McCracken wrote:
> Those are interesting numbers. That's pretty much the showcase for
> sharing, yeah.
>
<snip>
> I must mention here that I think most DB performance suites do their forks
> up front, then never fork during the test, so fork performance doesn't
> really factor in as much. There are other reasons shared page tables helps
> there, though.
>
Yes, that's why I mentioned the DB workloads as being more interesting.
> > Now I am off to figure out how Andi's mmap() randomization patch
> > interacts with all of this stuff.
>
> mmap() randomization doesn't affect fork at all, since by definition all
> regions are at the same address in the child as the parent (ie good for
> sharing). The trickier case is where processes independently mmap() a
> region.
>
> Dave
>
Hmm... I agree with your previous comment there, then. The only way the big
DB guys can start up that way is if they use MAP_FIXED and a pre-agreed on
address. Otherwise, they can't do lookups of DB buffers in the shared
storage area (i. e. this is basically user space buffer cache management).
It has to be the case that they all agree on what addresses the buffers are
at so each process can share the buffers.
So, that would argue that the mmap() randomization can't effect them either,
without breaking the existing API.
--
Ray Bryant
AMD Performance Labs Austin, Tx
512-602-0038 (o) 512-507-7807 (c)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
