Date: Mon, 7 Dec 2009 16:20:03 +0100 From: Mel Flynn <mel.flynn+fbsd.hackers@mailing.thruhere.net> To: freebsd-hackers@freebsd.org Cc: Linda Messerschmidt <linda.messerschmidt@gmail.com> Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE Message-ID: <200912071620.03371.mel.flynn%2Bfbsd.hackers@mailing.thruhere.net> In-Reply-To: <237c27100911260911w2674b79ds8ac447e900324dce@mail.gmail.com> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <867htduvwh.fsf@ds4.des.no> <237c27100911260911w2674b79ds8ac447e900324dce@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 26 November 2009 18:11:10 Linda Messerschmidt wrote:
> I did not mean to suggest that we were asking for help solving a
> problem with squid rotation. I provided that information as
> background to discuss what we observed as a potential misbehavior in
> the new VM superpages feature, in the hope that if there is a problem
> with the new feature, we can help find/resolve it or, if this is
> working as intended, hopefully gain some insight as to what's going
> on.
I tend to agree with this, though I don't know the nitty gritty of the
implementation, it seems that:
a) superpages aren't copied efficiently (at all?) on fork and probably other
workloads
b) vfork is encouraged for memory intensive applications, yet:
BUGS
This system call will be eliminated when proper system sharing mechanisms
are implemented. Users should not depend on the memory sharing semantics
of vfork() as it will, in that case, be made synonymous to fork(2).
So is this entire problem eliminated when system sharing mechanisms are in
place and vfork considered the temporary work around or is copying of
superpages a problem that remains?
--
Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912071620.03371.mel.flynn%2Bfbsd.hackers>