RE: anyone understand torvald's critique of freebsd?
>-Original Message- >From: Chuck Swiger [mailto:[EMAIL PROTECTED] >Sent: Saturday, April 22, 2006 7:51 PM >To: Ted Mittelstaedt >Cc: freebsd-questions >Subject: Re: anyone understand torvald's critique of freebsd? > > >Ted Mittelstaedt wrote: >> 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? > >I can't speak with certainty as to what someone else might >think; no doubt Linus >is entirely capable of explaining his own position should you >wish to inquire, The guy is bitching about an option that's not even turned on, thus it's not a legitimate criticism - there's an ulterior motive somewhere. He isn't going to explain this of course - if he was being honest he never would have bitched about it in the first place. >however :-) > >I think Linus doesn't care much for Zero-copy sockets because >for the common >case of 1500/1504-byte MTU, you end up wasting at least 60% of >a 4096-byte page >for each packet, and maybe ?three? times that much if your >hardware splits the >packet into separate pages for the mbuf header, the packet >headers, and the >packet data. > ram is cheap these days. I've seen things before that are a lot faster to do the memory-hogging way. If this is one of these then the ram usage shouldn't be an issue. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: anyone understand torvald's critique of freebsd?
Ted Mittelstaedt wrote: 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? I can't speak with certainty as to what someone else might think; no doubt Linus is entirely capable of explaining his own position should you wish to inquire, however :-) I think Linus doesn't care much for Zero-copy sockets because for the common case of 1500/1504-byte MTU, you end up wasting at least 60% of a 4096-byte page for each packet, and maybe ?three? times that much if your hardware splits the packet into separate pages for the mbuf header, the packet headers, and the packet data. I think FreeBSD doesn't enable Zero-copy sockets by default because those are legitimate criticisms, but there is some interest and potential for benefits from them, at least for some other circumstances like jumbo ethernet frames. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: anyone understand torvald's critique of freebsd?
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? Ted >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] Behalf Of Chuck Swiger >Sent: Saturday, April 22, 2006 5:38 AM >To: Peter >Cc: freebsd-questions >Subject: Re: anyone understand torvald's critique of freebsd? > > >Peter wrote: >> Does anyone here understand Linus Torvald's recent comments >on FreeBSD? >> >> http://bsdnews.com/view_story.php3?story_id=5735 > >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 >address space >rather than copying the sequence of bytes manually via a >message-passing paradigm. > >The former approach tends to be more efficient for small >amounts of data, >especially for things smaller than one page of memory (ie, all >non-jumbo network >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 >support shared >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 >called prebinding >that can minimize the work and memory overhead required for >runtime symbol >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 >fixed-VM shared >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). > >-- >-Chuck >___ >freebsd-questions@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-questions >To unsubscribe, send any mail to >"[EMAIL PROTECTED]" > >-- >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 > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: anyone understand torvald's critique of freebsd?
Peter wrote: Does anyone here understand Linus Torvald's recent comments on FreeBSD? http://bsdnews.com/view_story.php3?story_id=5735 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 address space rather than copying the sequence of bytes manually via a message-passing paradigm. The former approach tends to be more efficient for small amounts of data, especially for things smaller than one page of memory (ie, all non-jumbo network 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 support shared 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 called prebinding that can minimize the work and memory overhead required for runtime symbol 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 fixed-VM shared 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). -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: anyone understand torvald's critique of freebsd?
On Fri, Apr 21, 2006 at 08:56:29PM -0400, Peter wrote: > Does anyone here understand Linus Torvald's recent comments on FreeBSD? > > http://bsdnews.com/view_story.php3?story_id=5735 He's railing against an option (options ZERO_COPY_SOCKETS) that is not enabled by default in FreeBSD anyway for basically the same reasons he says. kris pgpsRs8SBmjEo.pgp Description: PGP signature
