Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, 19 Jun 2001, David S. Miller wrote: > > > Don't believe me that Solaris sucks here? Run this experiment under > Solaris-latest and Linux on a sparc64 system (using lmbench): > > Under Solaris: ./lat_proc fork > Under Linux: strace -f ./lat_proc fork > > I bet the Linux case does better than the Solaris run by some orders > of magnitude. That's how poor their fork/exit/switch code is. > > It's a very impressive difference: Script started on Tue Jun 19 17:49:30 2001 [kaboom@thing2 linux]$ ./lat_proc fork Process fork+exit: 563.7778 microseconds [kaboom@thing2 linux]$ ./lat_proc fork Process fork+exit: 565.5556 microseconds [kaboom@thing2 linux]$ ./lat_proc fork Process fork+exit: 568. microseconds [kaboom@thing2 linux]$ exit Script done on Tue Jun 19 17:49:46 2001 Script started on Tue 19 Jun 2001 05:51:38 PM MDT [kaboom@thing1 solaris]$ ./lat_proc fork Process fork+exit: 4249.5000 microseconds [kaboom@thing1 solaris]$ ./lat_proc fork Process fork+exit: 4212.5000 microseconds [kaboom@thing1 solaris]$ ./lat_proc fork Process fork+exit: 4241. microseconds [kaboom@thing1 solaris]$ exit script done on Tue 19 Jun 2001 05:52:19 PM MDT thing1 and thing2 are identical Sun Blade 100s. thing1 is running Solaris 8 (04/01 release), while thing2 is running 2.4.4 (Debian/unstable). later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Tue, 19 Jun 2001, David S. Miller wrote: axe_grind Don't believe me that Solaris sucks here? Run this experiment under Solaris-latest and Linux on a sparc64 system (using lmbench): Under Solaris: ./lat_proc fork Under Linux: strace -f ./lat_proc fork I bet the Linux case does better than the Solaris run by some orders of magnitude. That's how poor their fork/exit/switch code is. /axe_grind It's a very impressive difference: Script started on Tue Jun 19 17:49:30 2001 [kaboom@thing2 linux]$ ./lat_proc fork Process fork+exit: 563.7778 microseconds [kaboom@thing2 linux]$ ./lat_proc fork Process fork+exit: 565.5556 microseconds [kaboom@thing2 linux]$ ./lat_proc fork Process fork+exit: 568. microseconds [kaboom@thing2 linux]$ exit Script done on Tue Jun 19 17:49:46 2001 Script started on Tue 19 Jun 2001 05:51:38 PM MDT [kaboom@thing1 solaris]$ ./lat_proc fork Process fork+exit: 4249.5000 microseconds [kaboom@thing1 solaris]$ ./lat_proc fork Process fork+exit: 4212.5000 microseconds [kaboom@thing1 solaris]$ ./lat_proc fork Process fork+exit: 4241. microseconds [kaboom@thing1 solaris]$ exit script done on Tue 19 Jun 2001 05:52:19 PM MDT thing1 and thing2 are identical Sun Blade 100s. thing1 is running Solaris 8 (04/01 release), while thing2 is running 2.4.4 (Debian/unstable). later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - 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/
Re: hotmail not dealing with ECN
On Fri, 26 Jan 2001, James Sutherland wrote: > Except you can't retry without ECN, because DaveM wants to do a Microsoft > and force ECN on everyone, whether they like it or not. Don't be absurd. It's a compile-time option that nobody, not even Dave Miller, is forcing you to compile into your kernel. > If ECN is so wonderful, why doesn't anybody actually WANT to use it > anyway? Lots of people do. Lots of other people (such as, in this case, hotmail) will never upgrade their software until the groundswell of complaints is more expensive than their perception of the cost of upgrading later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail not dealing with ECN
On Fri, 26 Jan 2001, James Sutherland wrote: Except you can't retry without ECN, because DaveM wants to do a Microsoft and force ECN on everyone, whether they like it or not. Don't be absurd. It's a compile-time option that nobody, not even Dave Miller, is forcing you to compile into your kernel. If ECN is so wonderful, why doesn't anybody actually WANT to use it anyway? Lots of people do. Lots of other people (such as, in this case, hotmail) will never upgrade their software until the groundswell of complaints is more expensive than their perception of the cost of upgrading later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Software requirements in Changes document
On Mon, 8 Jan 2001, Matthias Juchem wrote: > Hi Chris, > > Comparing the Changes document for 2.4.0 against the one from 2.3.11 one > can see that many requirements were removed. Nine out of 22 are still > there. > Have the removed ones been unnecessary or only less important than the > remaining ones? I've not dug up 2.3.11 to double-check, but I'd imagine that's when it was trimmed so that only requirements which are new to 2.4 (ie, which aren't also true for 2.2) are listed.... later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Software requirements in Changes document
On Mon, 8 Jan 2001, Matthias Juchem wrote: Hi Chris, Comparing the Changes document for 2.4.0 against the one from 2.3.11 one can see that many requirements were removed. Nine out of 22 are still there. Have the removed ones been unnecessary or only less important than the remaining ones? I've not dug up 2.3.11 to double-check, but I'd imagine that's when it was trimmed so that only requirements which are new to 2.4 (ie, which aren't also true for 2.2) are listed later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Given an image, how can show its config?
On Sat, 23 Sep 2000, Keith Owens wrote: > I worry about anything that increases the on disk size of bzImage, even > if the extra data does not get loaded into kernel memory. > > 629590 2.2.16/arch/i386/boot/bzImage > 786273 2.4.0-test8/arch/i386/boot/bzImage > > cat .config System.map | gzip | wc -c > 107591 > > That would take my 2.4.0 bzImage to 893864, it does not leave much room > out of a 1.4Mb floppy for LILO files. So (a) make it optional during the configuration stage, (b) extend strip or some other user-land tool to rip 'em off afterwards for the corner cases that don't want them, or (c) do both (a) and (b). > This is all to protect those few poor 'administrators' who cannot keep > track of three separate files. We should not coddle such idiots, if > they cannot track 3 files they should not be configuring Linux. By reductio ad absurdum, we should also get rid of gcc. It's just coddling the idiots who can't do everything in assembly, after all, and therefore shouldn't be programming Linux If appending them doesn't hurt anything, and makes life easier for people, why not? It'd certainly make life easier for both kernel developers (since bug report quality will increase with the lowered chance of said idiots using the wrong System.map / no System.map) and for the ksymoops maintainer (since you'll finally have one standard place to have it look for System.map). Granted, there are other ways to do the same thing. We could, for example, combine what's now /boot and /lib/modules into one directory like /lib/kernel, and have make install drop bzImage, System.map, .config, and modules in /lib/kernel/'uname -r'/ . People would have to mount /lib/kernel as a separate partition like they currently do /boot, and they'd have to modify lilo.conf, ksymoops, and modutils, but after that it would work and we'd still have a semi-idiocy-proof standard > "Think of it as evolution in action". *shrug* It's "evolution in action" to append .config / System.map to bzImage as well. What's your point? later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Given an image, how can show its config?
On Sat, 23 Sep 2000, Keith Owens wrote: I worry about anything that increases the on disk size of bzImage, even if the extra data does not get loaded into kernel memory. 629590 2.2.16/arch/i386/boot/bzImage 786273 2.4.0-test8/arch/i386/boot/bzImage cat .config System.map | gzip | wc -c 107591 That would take my 2.4.0 bzImage to 893864, it does not leave much room out of a 1.4Mb floppy for LILO files. So (a) make it optional during the configuration stage, (b) extend strip or some other user-land tool to rip 'em off afterwards for the corner cases that don't want them, or (c) do both (a) and (b). This is all to protect those few poor 'administrators' who cannot keep track of three separate files. We should not coddle such idiots, if they cannot track 3 files they should not be configuring Linux. By reductio ad absurdum, we should also get rid of gcc. It's just coddling the idiots who can't do everything in assembly, after all, and therefore shouldn't be programming Linux If appending them doesn't hurt anything, and makes life easier for people, why not? It'd certainly make life easier for both kernel developers (since bug report quality will increase with the lowered chance of said idiots using the wrong System.map / no System.map) and for the ksymoops maintainer (since you'll finally have one standard place to have it look for System.map). Granted, there are other ways to do the same thing. We could, for example, combine what's now /boot and /lib/modules into one directory like /lib/kernel, and have make install drop bzImage, System.map, .config, and modules in /lib/kernel/'uname -r'/ . People would have to mount /lib/kernel as a separate partition like they currently do /boot, and they'd have to modify lilo.conf, ksymoops, and modutils, but after that it would work and we'd still have a semi-idiocy-proof standard "Think of it as evolution in action". *shrug* It's "evolution in action" to append .config / System.map to bzImage as well. What's your point? later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > I have no axe to grind, but I do have a different view. I'm the 1 in 30 > million men born with an extra Y chromosone (a double YY), so you are > pertially right there. DOuble YY males have a different brain structure > -- the lymbic system in my brain is so electrically active, it qualifies > as a third brain. Normal humans have two brains, left and right. Like > most double YY's I have three, left, right, lymbic. Fortunately for me, > my frontal lobes are normal and do not exhibit the wiring problems that > afflict 60% of double YY's, such as an uncontrollable urge to take an > axe and chop someone to pieces because they pissed me off. Not that any of this has anything to do with Linux kernel development, but you really should do a bit more background reading on 47,XYY. Incidence is much, much higher than you claim. Frequency estimates vary slightly with the study, of course, but it's usually somewhere around 1 in 1000 live male births (1 in 843 reported in Birth Defects 26:209-223, for example, and similar results in Prenatal Diagnosis 17:363-368. The *lowest* frequency I've ever seen reported was ~ 1/1250). Similarly, no scientific study I've ever seen has substantiated any of that nonsense about "lymbic wiring" or three brains. [1] There's a very small correlation between 47,XYY and: tallness, slightly reduced IQ, hyperactivity, ADD, and learning disabilities. AFAIK, there's no demonstrated physiological difference between 46,XY males (ie, "normal") and 47,XYY; average testosterone levels are the same in both, for example (AACE report, 1998). If you actually know of scientific studies substantiating the above claim of a physiological difference in the brain or any other physiological differences, I'd really appreciate references. Ditto for the list of individuals you claim had 47,XYY -- the only "famous" person I know of with any connection to the condition was Richard Speck, who falsely claimed to be 47,XYY in an attempt to get leniency for his murders. I'm curious about your references because it's a condition which is quite common, but which is very rarely diagnosed precisely because it usually has no effect Sorry about responding to this on linux-kernel instead of privately, but 47,XYY is a condition for which most popular "knowledge" is both wrong, and quite persistent in its popularity and acceptance; furthermore, this incorrect "knowledge" is often detrimental to those with the condition (ie, Psychological Bulletin 78:209-233). Historically, it was popularly thought that 47,XYY was a condition leading to hyperaggression, criminal behavior, etc., and so those with 47,XYY were often treated accordingly. The scientific reality is far more boring; most males with 47,XYY -- like most males with 46,XY -- are as normal as males ever are, and should be treated accordingly ;-). later, chris [1] I suspect you're conflating two very different conditions, Klinefelter syndrome (47,XXY) and 47,XYY. Some studies (ie, J Neurol Neurosurg Psychiatry 66:628-32) have demonstrated neurological differences for subjects with Klinefelter syndrome, but they have simultaneously demonstrated that neurological structures in 47,XYY subjects are no different than in age-matched 46,XY controls. -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
On Thu, 31 Aug 2000, Keith Owens wrote: > Before Rusty tells me that not everybody uses modules, > /lib/modules/ can exist even if the kernel has no modules, it > just needs a simple Makefile change. Think of /lib/modules/ > as a standard place to store information about kernel . I like the idea of a standardized repository in /lib matching the kernel. But if it's going to do more than modules, why not rename it something more appropriate, like /lib/kernel/ or /lib/linux/ or even (less preferably) /lib/? later, chris -- Chris Ricker [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
