anyone understand torvald's critique of freebsd?
tedm at toybox.placo.com
Sat Apr 22 19:29:08 UTC 2006
Then why does Linus think manipulating the VM page table mappings
is bad? That is, why does he -really- think it's bad, not the
publically-given reason? Is it because Linux is extrordinairly
inefficient in page table mappings due to some structural decision
that Linus made that cannot be reversed now, that it could never
be any good at it? Or is there some other reason?
>From: owner-freebsd-questions at freebsd.org
>[mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Chuck Swiger
>Sent: Saturday, April 22, 2006 5:38 AM
>Subject: Re: anyone understand torvald's critique of freebsd?
>> Does anyone here understand Linus Torvald's recent comments
>Sure. There are different ways of moving data between the
>kernel and userland;
>the classic mechanism involves copying data from a wired-down
>page in kernel
>space allocated to network memory buffers to a userland page
>via copyin() and
>copyout() (or equivalents).
>Mach (and apparently the ZERO_COPY_SOCKETS option to FreeBSD)
>manipulate the VM
>page table mappings to make that page visible in the process
>rather than copying the sequence of bytes manually via a
>The former approach tends to be more efficient for small
>amounts of data,
>especially for things smaller than one page of memory (ie, all
>traffic); the latter approach tends to better for things which
>are bigger in size.
>The Mach VM has more overhead to its operations because the
>VMOs are more
>complicated to work and a given workload will result in
>comparatively larger VMO
>datastructures than the less-complicated approaches to doing
>VM. On the other
>hand, Mach was the first or among the earliest platforms to
>libraries, dynamic loading of objects into user processes
>(dlopen vs. dso) and
>into the kernel, and has somewhat better scaling in the face of
>gigabytes of RAM
>and VM usage than most Unix flavors do (outside of Solaris,
>although FreeBSD is
>pretty decent nowadays too).
>Mach handles mapping shared libraries into VM via a technique
>that can minimize the work and memory overhead required for
>relocation, which tends to big win if you are running a lot of,
>say, Java or
>Perl processes that make extensive use of runtime
>class-loading, yet is flexible
>enough to deal with collisions if needed (whereas the older
>libraries were subject to evil nasty conflicts if your data
>segment grew too big
>and overlapped a library's chosen address space, or if two
>libraries wanted to
>be mapped into the same spot).
>freebsd-questions at freebsd.org mailing list
>To unsubscribe, send any mail to
>"freebsd-questions-unsubscribe at freebsd.org"
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 4/21/2006
More information about the freebsd-questions