Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||16 May 2000 - 24 May 2000||(21 posts)||Linux On Hand Calculators|
|2.||18 May 2000 - 28 May 2000||(89 posts)||Things To Do Before 2.4: Saga Continues|
|3.||21 May 2000 - 29 May 2000||(16 posts)||Linus Discusses Transmeta Chips|
|4.||22 May 2000 - 25 May 2000||(21 posts)||The Future Of sleep()|
|5.||22 May 2000 - 23 May 2000||(12 posts)||The LKBS Linux Kernel Benchmark Suite|
|6.||23 May 2000||(3 posts)||Proposal For Kernel Changelogs|
|7.||24 May 2000||(5 posts)||Virtual Memory: Linux Vs. BSD|
|8.||25 May 2000||(1 post)||Linus Releases 2.4-test1 And Goes On Vacation|
|9.||26 May 2000 - 29 May 2000||(5 posts)||Alan Releases His First 2.4-test1 ac Patch|
Mailing List Stats For This Week
We looked at 1084 posts in 4517K.
There were 419 different contributors. 180 posted more than once. 128 posted last week too.
The top posters of the week were:
1. Linux On Hand Calculators
16 May 2000 - 24 May 2000 (21 posts) Archive Link: "Linux on the TI-89/92[+]???"
People: Kenneth C. Arnold, Vojtech Pavlik, William Astle, Andrew McNabb, Daniel Egger, Dr. Kelsey Hudson, Pavel Machek
Kenneth C. Arnold asked, "since Linux supports the M68k family down to the M68020 last I checked, would it be _even remotely possible_ to do a port to the TI-89 / TI-92[+], which are graphing calculators based on the M68000?" Vojtech Pavlik was optimistic, replying, "I think the TI-92+ (preferably 3x overclocked, too) should be able to run uCLinux quite OK. Enough flash (1 MB) for read only root filesystem, enough ram (640 KB) for running the OS - not as good as the PalmPilots, but it could fit in there."
Dr. Kelsey Hudson first thought that those calculators used the 16-bit 6809,
not the 32-bit 68K. (William Astle
emails me privately to add,
Elsewhere, Andrew McNabb was doubtful that anything could be done to get Linux on those machines. He explained, "Linux only works on Mac II's (which have 68020's) that have a certain MMU. I imagine that as you go to a 68000, even more stuff will be fouled up. There are also major issues about I/O, installation, etc. I think that trying to port to a TI would be a waste of time." But Daniel Egger replied that 'uLinux' would run on systems without memory management units (MMUs), and added, "even a port to the dragonball (a CPU with Motorola 68000 core and embedded connectivity) exists and is running fine for me." Kenneth asked for some pointers to documentation describing the differences between the dragonball and the M68000, and Daniel gave him a pointer to MC68328: DragonBall[tm] Integrated Microprocessor.
Pavel Machek felt that the TI-92 was really not that interesting, and a fairly pointless goal for a Linux port. Vojtech replied simply, "TI92 is cheap, has clock up to 25 MHz, and runs half a year on four AA batteries ..."
2. Things To Do Before 2.4: Saga Continues
18 May 2000 - 28 May 2000 (89 posts) Archive Link: "Linux 2.3.99pre9-2 JOB list"
Topics: Compression, Disk Arrays: RAID, Disks: IDE, Disks: SCSI, FS: FAT, FS: NFS, FS: NTFS, FS: UMSDOS, I2O, Networking, PCI, Power Management: ACPI, Real-Time, SMP, Samba, Security, USB, Virtual Memory, VisWS
People: Alan Cox, Craig Kulesa, Rik van Riel, David Ford, Alexander Viro, Jeff Garzik, Vojtech Pavlik, Christopher Thompson, Martin Mares, Andrea Arcangeli, Juan J. Quintela, Ben Collins
Alan Cox posted the latest in his series of lists of things to do before 2.4 could come out. For the last one, see Issue #66, Section #5 (24 Apr 2000: To Do Before 2.4: Saga Continues) . This week, he listed:
Fix Exists In -AC Tree
Fix Exists But Isnt Merged
To Do But Non Showstopper
Probably Post 2.4
David Ford replied to several of these items. To item 1.1 (Tulip hang on rmmod (fixed in .51 ?)), he said that no, this was still crashing as of 2.3.99pre3. To item 1.4 (VM needs rebalancing or we have a bad leak), he replied that Andrea Arcangeli's 'classzone' patch fixed it all back up again. Rik van Riel reported that the 'classzone' patch was unstable and incorrect. He suggested Juan J. Quintela's latest patch as attempting to fix the known problems. He and Andrea proceeded to have a brief dispute over the relative merits of various attempts to deal with the recent VM problems. At one point, Craig Kulesa had the last word, "Classzone was presented and discussed extensively on the linux-mm list at the end of April. Start here, follow the thread onwards: http://mail.nl.linux.org/linux-mm/2000-04/msg00172.html."
Elsewhere, Rik replied to Alan's original list, to item 4.13 (Finish sorting out VM balancing (Rik Van Riel)); continuing the credits, he said, "And Juan Quintela and a few other #kernelnewbies folks. The patch seems ready and better than 2.2 or 2.3 has ever been. I'm currently testing stuff and it looks quite good, but as usual beta testers are wanted to see if it works on all workloads. Please try the patch at: http://carpanta.dc.fi.udc.es/~quintela/kernel/." Ben Collins reported good results with the patch, but there was no discussion.
In David's original post, he also suggested as "to do but non-showstopper", "2.3.99-pre9-1, I'm able to mount the floppy any given number of times over and over without unmounting it. No errors seem to happen and umount needs to happen for each mount before the device is no longer in use." Alexander Viro replied, "And that's a bug which way? Yes, we have multiple mounts now. Yes, fs is busy until you undo each mount (obviously). Yes, you can mount over the mountpoint. You are getting precisely what you are asking for - operation used to be illegal, but now it's perfectly OK. So it succeeds. What's the problem?" There was some interest in why such a feature had been added, but no real explanation surfaced. (Stephen Landamore emailed me to point out that this was discussed in Issue #64, Section #9 (14 Apr 2000: More 'devfs' Discussion) . Thanks, Stephen! -- Ed: [06 Jun 2000 23:00:00 -0800]
Also in his original post, to item 6.9 (PCMCIA/Cardbus hangs, IRQ problems, Keyboard/mouse problem (may be fixed ?)), David replied that no, this was nowhere near fixed.
Jeff Garzik also replied to Alan's list. He reported that item 1.32 ("Fix all remaining PCI code to use new resources and enable_Device"), although listed as fixed, was not. Also, item 4.23 ("8139 + bridging fails"), was listed as having a fix that had not been merged. But Jeff said, "a 8139too patch just went to Linus that should fix all issues related to RTL8139 (original) chips." He also pointed out that items 6.16 ("pci_socket crash on unload ") and 7.14 ("PCMCIA crashes on unloading pci_socket") seemed to be identical reports. There was no reply to any of his reports.
Alexander also replied directly to Alan's list, saying that item 2.3 (Complete vfsmount merge (Al Viro)) had been finished.
Vojtech also replied directly to Alan's list. To item 7.18 (Fix boards with different TSC per CPU and kill TSC use on them), he addended, "AND notebooks that vary CPU (and TSC) clock (Toshiba Satellite, IBM ThinkPad) to save power." Christopher Thompson announced in reply:
I have now completed and tested my second TSC patch. It is available at: http://hypocrite.org/linux/tsc.patch.new.tar.gz
This works with 2.3.99-pre8 at least, probably most others. This one disables use of the TSC by an option in the configuration (i.e. make config, make menuconfig, whatever) and therefore has NO performance impact on TSC-enabled kernels. The disadvantage is that this is another option to set in your configuration.
The old patch is available at: http://hypocrite.org/linux/tsc.patch.new.tar.gz
And works for at least 2.3.99-pre6 and pre8, probably most others. This one doesn't use any configuration but rather, determines the situation on bootup. There were some legitimate complaints about this.
I welcome comments and suggestions for improvement. I specifically would like to know how well it works for you and whether it works on a laptop which varies CPU speed (particularly an SMP laptop if such exists).
Just to note: Win2k *does* allow SMP machines with different speed CPUs, despite several people's claims to the contrary.
Martin Mares also replied to Alan's list. To item 1.32 (Fix all remaining PCI code to use new resources and enable_Device), he replied, "Not yet, but thanks to Jeff Garzik many drivers have been already converted." And to item 6.13 (pci_set_master forces a 64 latency on low latency setting devices.Some boards require all cards have latency <= 32), he added that this was fixed in 2.3.99-pre7.
3. Linus Discusses Transmeta Chips
21 May 2000 - 29 May 2000 (16 posts) Archive Link: "8259A initialization with AMD SC520 chip (586)"
People: Linus Torvalds, Jamie Lokier
In the course of discussion, Linus Torvalds had some things to say about his work at Transmeta. Speaking of whether Transmeta chips would morph out empty loops, he remarked:
We'd love to, but we don't touch code like that. We could have made the old bogomips give infinite values if we _really_ wanted to, but code like that has one purpose, and one purpose only: delaying. So we never remove those kinds of loops.
(And in any case it would have been extra logic - empty loop removal is very much a special case, so whatever we did would have been an extra wart rather than anything that came really naturally to the way morphing works..)
In a later post, he added:
There's a ton of funky stuff we _could_ do if we wanted to implement the x86 "right". Sadly, we have to be quite careful ;)
[ You _really_ don't want to know about taking page faults in the middle of a task switch that is the result of a task gate being used to handle another page fault, which in turn happened while we were loading the second part of a page-crossing 32-bit word. Question: do you mark the page table entry for the incomplete part that you already checked as accessed or not? ]
Jamie Lokier replied that actually, he did want to know, since he was busy writing an x86 formal spec. Linus expounded:
It actually depends on the CPU, and the type of access.
If it's a "atomic" 32-bit access, you don't mark the PTE accessed, because the page fault will have been noticed before any data was actually fetched. But that is not true for some data that has more "structure" to it that can be loaded as separate pieces and then a page fault part-way through can have already set some of the accessed bits.
The reason it is CPU-dependent seems to be that with speculative loads and out-of-order execution the whole thing becomes much more subtle, and "separate pieces" is no longer the firm thing it used to be. A Pentium core will act differently from a PPro core in many of these special cases.
Nobody sane obviously should ever care. It's hard to even test for, in many cases. We have some rather insane tests, and there's a number of differences between different chips.
Note that many of these things aren't even documented to work. Intel explicitly documents that if you use task switching hardware the TSS should all be on a single page etc. And nobody uses the hardware any more now that even Linux does it all in software. But it's often more painful to be different and have to convince everybody that those differences do not matter than to just try to look exactly like everybody else as far as humanly possible.
4. The Future Of sleep()
22 May 2000 - 25 May 2000 (21 posts) Archive Link: "[PATCH] bttv driver II"
People: David Woodhouse, Linus Torvalds
In the course of discussion, David Woodhouse remarked, "How many _valid_ (i.e. non-racing) uses of sleep_on() exist in the kernel at the moment? I suspect it's a miniscule proportion of the occurrences," and Linus Torvalds replied:
We've for the longest time occasionally considered just removing it. Th enotion of "sleep_on()" is a very simple notion, and people understand what it's all about, but most of the uses tend to be buggy.
It might be a good idea to remove sleep() altogether during early 2.5.x. Please remind me. It shouldn't be that painful for most people (but there are probably tons of drivers that need to be updated and tested - 2.5.x is definitely the right point to do this).
5. The LKBS Linux Kernel Benchmark Suite
22 May 2000 - 23 May 2000 (12 posts) Archive Link: "[RFC] Linux Kernel Benchmark Suite"
People: Guus Sliepen, Andre Hedrick, Kip Macy, Larry McVoy, J. Robert von Behren, Victor Yodaiken, Rik van Riel, Dominik Kubla
Guus Sliepen felt that because of all the recent performance complaints, there really needed to be a standard benchmark suite. He proposed:
I suggest creating LKBS:
I don't know what you think of it, or if there already are such things. If not, I'd happily volunteer to start this project.
Andre Hedrick reached for his megaphone, turned the knob up to 10, depressed the plastic trigger mechanism, and bellowed, "GO FOR IT!!!!!!!!" . He released the trigger, stowed the megaphone, and continued soberly, "Linux needs a standard so that we can do hardware comparisions and provide manufacturers a tool to optimize for Linux. Currently anyone using OTC hardware it is tainted with "WinBench". Specifically DISK caching tables are all tweaked for the other OS.........."
Phil Wilshire suggested joining the Real Time Linux mailing list, by sending "subscribe testing" in the body of a message to firstname.lastname@example.org. He also volunteered to do some work on it himself. Guus replied, "I prefer linux-perf, not only because it's name and the fact that it appears more general than a list at realtimelinux, but also because it has more members, which will give this project more momentum." He added, "I've already set up a (very preliminary) web page at http://www.phys.uu.nl/~sliepen/lkbs/. I'll try to make Rik van Riel host it on www.nl.linux.org (which is a portal site so many people will visit it, and it has relations with lots of other Linux user groups), unless you or someone else has an even better alternative ofcourse :)."
Victor Yodaiken suggested that 'lmbench' would be the natural starting point for LKBS. Kip Macy agreed with this, and added peripherally, "Out of academic curiousity I ran lmbench on all 60 development kernels. If anyone is interested in the results I will post them to my website." Victor replied with extreme interest, but no URL was posted.
Larry McVoy had some encouragement to offer as well:
I'd really love it if this effort got started. I have a huge backlog of lmbench submissions that I have not processed and put up on the web. I just don't have time these days but the data is there.
Furthermore, I've done a lot of work like what you are proposing and I'd like Linux to benefit from that, but I can't start a project to do that. On the other hand, if there are people who want to work on it, I can certainly help focus the efforts. I've literally spent years doing this sort of thing at SGI & Sun and it seems a waste that I'm not passing on that knowledge/experience. So I'll help if someone else wants to drive.
Guus was very happy about this, and said:
I've just checked out lmbench, that is indeed what I envisioned, except that it does some general benchmarks that apply to most Unices, and I think many developpers like to see their own Linux specific benchmark to go into that too, so they can gather information about the performance of their driver/patch. It was also a little hard to find (I had to use FTPsearch and follow some links), you should put it on Freshmeat IMO :).
This, combined with an automated repository that would gather all information and send digests on request to developpers, would certainly benefit development I think.
J. Robert von Behren was also enthusiastic:
This definitely sounds like an excellent idea to me. I'd be happy to help out, so if you'd like a hand in organizing this, setting up the benchmarks, or creating the site for the benchmark results let me know.
IMO, there are two comparisons that would be really useful in helping to pinpoint performance problems or bugs in the kernel:
It would also be very nice to link to lists of changes between versions, to help people figure out _why_ performance certain changes in performance occurr.
It might makes sense to move a discussion of this off the kernel list. I'd be happy to set up a discusion list for this - just let me know if people are interested.
Dominik Kubla also felt the topic had left the realm of linux-kernel, and suggested moving to linux-perf, even though that list had been pretty quiet for several months. To subscribe, send "subscribe linux-perf" in the body of an email to email@example.com. Guus replied that he was on that list, and invited others to follow him there.
End Of Thread.
6. Proposal For Kernel Changelogs
23 May 2000 (3 posts) Archive Link: "RFC: kernel changelogs (semi-long)"
People: Jeff Garzik, Tim Waugh
Jeff Garzik proposed:
When analyzing a kernel code change, it is sometimes not possible to deduce the true meaning of the change from the diff itself. When this happens, analysis of the surrounding code is required, sometimes accompanied by mailing list searches and such.
Occasionally, we even have bad patches which get applied and then un-applied, over the course of six months or a year. From many perspectives -- long term maintenance, short term change evaluation, general code understanding -- a small changelog entry for each change seems advantageous. I think GNOME, egcs, and other projects using changelogs have experience which bears this out.
Since the kernel doesn't have a canonical source code repository, we must current on the human (but still brilliant) minds of Linus, Alan, DaveM, sct, tytso, and others. Therefore I propose to have kernel changelogs.
Disadvantages exist too... Gotta get Linus, Alan, and other big contributors to agree. It takes more time, especially for people like Alan who feed lots of changes to Linus. And people will inevitably bicker on changelog entry format.
Three small technical notes:
Overall I believe the advantages outweight the disadvantages. I've always felt that sharing knowledge around has a positive effect, and IMNSHO the Linux kernel community occasionally suffers a bit due to lack of documentation on changes.
Tim Waugh replied, "There already is a drivers/char/ChangeLog by the way, although it hasn't been touched in over a year. ;-)" and Jeff replied, "Unfortunately, kernel changelogs imply Linus enforcement and Alan agreement, otherwise it will fail miserably due to gaps in the docs...." The thread ended there.
7. Virtual Memory: Linux Vs. BSD
24 May 2000 (5 posts) Archive Link: "Linux VM system vs. BSD ditto"
Topics: BSD: FreeBSD, Microkernels: Mach, Virtual Memory
People: Gerard Roudier, Juan J. Quintela, Rik van Riel
Gustav Kristoffer Ek had been hearing that BSD's virtual memory system was faster than Linux's, when memory got tight. He'd heard that this was because Linux used a "one-hand" algorithm, while BSD used "two-hand", and asked what that was all about.
Rik van Riel confirmed that BSDs VM system was in fact faster than Linux's in those situations, and said that he and others were busily trying to fix that. He added, with a bang of the fist, that neither Linux nor FreeBSD used the one- or two-hand algorithms, and Gerard Roudier expanded:
Linux-2.2 is using the 'one-hand' but 2.3 uses a single LRU. Current fine BSD O/Ses seem to use the active/inactive queue algorithm that may well come from Mach (historians should confirm).
The 'one hand' algorithm made full sense at the time memory size were not that large. IIRC, the 'two hand' algorithm has been invented by BSD guys when memory size increased, for the reason it took too long to do a revolution of the map. This let me think that the 'two-hand' algorithm was rather an hack than a really superior algorithm. Btw, this happened may-be 10-15 years ago, so this may well be just off-topic nowadays. :)
Rik and Juan J. Quintela gave pointers to the 'linux-mm' mailing list archives, but did not point to any particular thread.
8. Linus Releases 2.4-test1 And Goes On Vacation
25 May 2000 (1 post) Archive Link: "[SPOILER] Don't read if you don't like spoilers !"
People: Linus Torvalds, Alan Cox, Mario Mikocevic
Mario Mikocevic noticed a 2.4 directory in ftp.kernel.org, and a message from Linus Torvalds in ftp://ftp.kernel.org/pub/linux/kernel/v2.4/README-2.4, saying:
It doesn't really exist yet.
But I'll be gone for three weeks, and in the meantime there's a "2.4.0-test1" kernel here. It's not a real 2.4.0 release, but we should be getting closer. There's going to be other test-kernels after this one, and we'll find bugs. And bad behaviour. And wonderful features which we'll document some day.
Alan Cox is most likely to maintain a "2.4.0-ac" series while I'm gone. Not the same thing as 2.4.0 either, but by testing these test-kernels out and giving feedback, we'll get to that some day.
Have fun. And let's see how many people find this without it even being announced ;)
(ed.  I suspect that Linus et al would like to shed a more realistic light on version numbers in general. Proprietary vendors made version numbers such a big deal, because they had to create a product and then stand by it and claim it was the best thing in the Universe. Actually, those best-in-the-universe releases were always largely untested because no one had used them yet! Same with kernel 2.4.0, when it finally comes out. It won't be a finished, final, stable kernel; just one more link on a long chain, a link that means primarily, "now we will try to stabilize the code." The whole idea of accompanying particular releases with lots of fanfare is a holdover, a "legacy feature" once needed for compatibility with other commercial PR teams. But I don't remember seeing it in POSIX.)
9. Alan Releases His First 2.4-test1 ac Patch
26 May 2000 - 29 May 2000 (5 posts) Archive Link: "Linux 2.4.0test1-ac1"
Topics: Disk Arrays: RAID, FS: procfs, I2O, PCI, Sound: Maestro
People: Alan Cox, Tigran Aivazian, Thomas Graichen, Tony Hoyle, Jens Axboe, Matthew Wilcox, Andy Henroid, Francois Romieu
Alan Cox released his first 'ac' patch against the 2.4-test kernel, giving some changelog information:
Base point differences between Alan's tree and Linus
There was not much discussion.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.