Kernel Traffic #88 For 9 Oct 2000

I disagree.

Yes, they have no _code_ in common. They have a completely distinct history, and they have distinct users.

But they are, in the end, the same thing. They are higher-level drivers that do conceptually the same thing, namely manage the low-level drivers as a potentially common resource.

In fact, some of the MD and LVM code do the same things. CONFIG_MD_LINEAR and CONFIG_BLK_DEV_LVM can be used to do the same thing (and I think LVM can do striping too). Yes, they have different interfaces, but they have the same issues.

It makes sense to group them together. Neither is a true hardware driver, and they have many common goals.

Yes, we have all thes _historical_ reasons why people think "md" refers to the particular RAID code in question. But so what? LVM is also very much an issue of handling multiple disks, and organizing them. "md" as shorthand for "multiple disks" works fine for LVM too.

I think most people who complain about the "md" directory naming do so just because they have this emotional attachement to "md" as the particular implementation that it implied a year ago, and they've gotten used to that association.

But I don't think there is anything wrong with grouping RAID and LVM under the title "md", and just leaving it as such.

If you look at pre6, the comments changed a bit to make it clearer that MD now includes both LVM and RAID as equal partners, and I don't see any problem with that setup. Does anybody have any real technical arguments against it, or are all arguments of the type "I'm used to 'md' meaning RAID, and I am not willing to reconsider"?

Sure, it could be called "sm" for "storage management" too. Or "dm" for "disk management". Or it could be under drivers/block/multi. Or it could validly be called any number of things. I just think that "md" was a valid name too, and I got the patch with that name, so..

I'll soon (as soon as I'll finish some other thing that is just work in progress) release a classzone against latest's 2.4.x. My approch is _quite_ different from the curren VM. Current approch is very imperfect and it's based solely on aging whereas classzone had hooks into pagefaults paths and all other map/unmap points to have perfect accounting of the amount of active/inactive stuff. The mapped pages was never seen by anything except swap_out, if they was mapped (it's not a if page->age then move into the active list, with classzone the page was _just_ in the active list in first place since it was mapped).

I consider the current approch the wrong way to go and for this reason I prefer to spend time porting/improving classzone.

In classzone the aging exists too but it's _completly_ orthogonal to how rest of the VM works. classzone had only 1 bit of aging per page to save mem_map_t array so I'll extend the aging info from 1 bit to 32bit to make it more biased.

This is my humble opinion at least. I may be wrong. I'll let you know once I'll have a patch I'll happy with and some real life number to proof my theory.

In the meantime if you want to go back to 2.4.0-test1-ac22-class++ to give it a try under swap to see the difference in the behaviour and compare (Mike said it's still an order of magnitude faster with his "make -j30 bzImage" testcase and he's always very reliable in his reports).

static char * envp[MAX_INIT_ENVS+2] = { "/kernel-traffic/HOME=/index.html", "TERM=linux", NULL, };
execve("/bin/foo/index.html",argv,envp);

Just because you can do something does not, however, make it a good idea...

Patches for Sun E10000 are in the current vger cvs, details for accessing this can be found at <http://vger.samba.org/>. You too can have a linux box that compiles kernels in 20 seconds.

I have set up some information at:

<http://linuxcare.com.au/anton/e10000/>

Thanks to Craig Armour <c.armour@its.uq.edu.au>, Tony Jago <t.jago@its.uq.edu.au> and Mark Suter <suter@its.uq.edu.au> from the University of Queensland for arranging access to such a machine.

It depends on the size of the room of course, but it wouldn't fit in mine and you also need 3phase electricity connection to have a chance to power it up :). Pretty amazing. I ported linux to it and booted the linux kernel the first time into it in April this year with the kind help of Jay Estabrook (the machine I was using for doing the port had ""only"" 11 CPUs and 8G of ram :).

To make it to work faster when the memory and CPUs of more of one node are used by linux (btw currently we can't run more than one linux kernel at once) we need to do real NUMA (not only DISCONTIGMEM). That means at least duplicating the kernel on each node, and adding NUMA heuristics into scheduler and allocator along the lines of what SGI folks are doing for Origin 2K.

The allocator also mandatory needs part of classzone to be able to make decent decisions. (putting the memory of different NUMA nodes internally to a pgdat_t as different zones as it's been proposed in linux-mm is a broken hack that can't work right) Infact saying that classzone have problems with NUMA looks silly to me as it's the other way around as far I can see.

Both the current code and classzone will need some adjustments to work fine (as in: reasonably efficient) with NUMA.

If the classzone idea can be extended to NUMA with more readable (== maintainable) code than the standard zoned allocator, I'm all for having it integrated...

(I'm not sure if classzone will have many benefits in "normal" setups, but with NUMA I can see the idea giving a lot more performance benefits)

uh, this will be unpleasantly familiar to anyone who was reading the linux-usb mailing list in Dec 99, when George said, roughly "you are all so full of shit that you're not worth working with, so on Monday we will begin designing our own USB for Linux".

Linux USB has survived quite nicely in spite of this, which bodes quite well for ARM-linux ;)

Since when it is decided by community? It's not a democracy. You don't like it - maintain your tree and accept/reject whatever you want.

I find plonk-by-domain silly, but the contents of filters is the private business of person using them. Period. We've been through that quite a few times when Alan-uses-*R*S threads appeared on the list. Enough, already.

Please note that at every instance, George has totally ignored my suggestions and advice. I have ended up taking this last straw to prevent any further flame wars or other nastyness between us.

I therefore believe that it is in the greater good for the ARM Linux community that discussions between George France and myself cease.

Every instance??? I think this is an exaggeration, don't you? If you really want to prevent a flame war stop poking at me.

As I said in my last message to you, I am tired of arguing with you.

I'm finally back from Linux Kongress and Linux Expo and will look at the latest tree and integrate the fixes I made while on the road later today (after I get some sleep).

I have fixed this particular bug, which was caused by us moving unfreeable pages to the inactive_dirty list and back again, while not accomplishing anything useful.

The fix for this is trivial and I'll post it later today (cleaned up and working in the current source tree).

Yes we (IBM Linux Technology Center RAS Team) are. If you have ideas/concerns/requirements please make them known. We are at the point of deciding what to attack. We have other dumping technologies on other OSs we could model a Linux enhancement on. There are many things we'd like to see incorporated, the question is how not to boil the ocean. Here are some of the ideas we are thinking about:

• Multi-process/multi-thread
• Customisable memory ranges/object types
  • Code/Stack/Dynamic allocations
  • System Objects:
  • File-system
  • Memory Management
  • Device Management
  • Process/Task Management
  • (Physical memory ranges)
• Multiple (non-fatal) Triggers:
  • Trap
  • Command
  • API
  • Automated (via DProbes)

I was aiming at the simplest and in my mind most obvious thing, which is to have the standard ELF coreer dump handle multiple threads in the same way as it does on many other systems. The lack of these causes shrieks of amazement from many of our customers :-(

This is not rocket science, and there are already debuggers (gdb, our product TotalView, ...) which know how to understand such core dumps if only the kernel produced them.

Now that the kernel has mechanisms for finding all the threads in a process, the actual dump writing should be relatively simple. (You need to write the appropriate register notes for every thread, rather than just one).

You seem to be aiming for a much more featureful solution (also applicable to checkpointing ?), I'm simply aiming to catch up with existing practice on many other operating systems.

I think one needs to be careful of not letting a desire for the perfect solution prevent deploying a useful solution while working out the best one, in this case.

When a multithreaded application "dies" due to one of the threads failing in an unexpected and unrecoverable way, there probably isn't, at that point, a "same state" for the threads to be in, and an non-coherent dump, while still difficult to use, is more useful than not dumping any state at all, and often is coherent enough to use anyway.

Does anyone actually want /proc/locks to stay? The data structure which allows it to be generated is now only used by the code to print out /proc/locks. If it could be deleted, a lot of code and data pointers could go away. I don't think any program depends on its existance and it's a pretty ugly file anyway (exposing kernel pointers to userspace? looks like pure debug code).

Speak now, or it shall be gone.

OREM -- The CEO of a local computer company says Microsoft has backed off on a threat to sue his Orem company over alleged violations of intellectual property rights.

"Their attorney, Linda Norman, called us Thursday night and issued an apology," Jeff Merkey, CEO of Timpanogas Research Group in Orem, said in a phone interview from the Networld Interop trade show in Atlanta on Friday. "She assured our attorney, Andrew McCullough, that there will be no lawsuit."

Microsoft spokesman Jim Cullinan said he couldn't immediately speak of the agreement between Bill Gate's company and Timpanogas.

However, he did say, "There is no truth there is a lawsuit, but Microsoft does take its (intellectual property) rights very seriously."

"It all kind of got out of proportion," Merkey said of the threats. He spoke about them only after some of his private e-mail was intercepted and posted on the Internet.

Timpanogas is a corporation formed by Merkey and other former Novell employees to develop networking, clustering and storage software solutions. The company had been working with Microsoft engineers on Timpanogas network file system products for Microsoft's Windows NT 2000.

Development involved Microsoft intellectual property. Like a lot of software companies, Timpanogas was also working with other operating-system developers that Microsoft considers competitors, such as Linux, developing Timpanogas network products that would run with Linux.

"They (Microsoft) basically gave us a license to build some tools to run on Windows NT 2000," Merkey said.

At one point, Timpanogas wrote some conversion tools to convert NetWare and Linux file management systems and were giving them to Microsoft.

But he said they also gave them to some Microsoft customers who were using the Microsoft network file systems on Linux.

But Merkey said this and his e-mail communications with Andre Hedrick, a Linux disk engineer, ruffled Microsoft's feathers.

"Microsoft has threatened us with litigation due to our support of Linux NTFS development, and we have dissolved our NTFS licensing agreements with Microsoft...," Merkley wrote in one of his e-mails.

Merkey said he has no idea how it happened, but their e-mails first were posted on an Internet weekly Linux newsletter and reposted Tuesday on Slashdot.org.

Merkey said Norman described the fracas as "an apparent miscommunication. And she also said 'please don't post those e-mails.' "

Pat Christian can be reached at 344-2556 or at pchristi@heraldextra.com

Maybe MS made this decision because they weren't willing to force users into making the choice of either continuing to use NT or permanently ditching it without the chance of going back ;)

(and when somebody has an NTFS volume and wants to use Linux with it, it's not that hard to guess which way they're migrating their system)

They semed very sad that they had damaged their relationship with me, and Linda was more concerned as to whether I was still angry at them more so than any issues with their IP. I really like a lot of the folks who work up there, particularly Jim Allchin and David Geobel (and Dan Neault -- he's really a great guy) and I think they did not like the idea that one of their golden geese might fly away forever. I am happy to work with them moving forward. I just don't respond well to threats, and never have -- but who does.

They are really stressed up there right now with the DOJ stuff and everything that's happenned, and I think the whole Linux thing is also getting them down. We'll see where it goes, but I am gad they are doing what's right here and putting their customers first. If an MS customer wnats to use Linux and W2K, they should be helping them, and I think perhaps they have come to realize this now.

People are starting to realise they have a choice, so MS will have to become more customer friendly.

Even if Linux doesn't "win the game", knowing that we did something to make computing bearable again for the system administrator is a good thing ;)

It is fun, but I was not ware that scale of this mess was so great. All I did was to make the request for Microsoft not to blow things out of proportion. Sheesh, by letting us, without noise or action, create R/W support of NTFS for Linux they would have been able to give the appearence that they were behaving.

Regardless, congrates on using the entry point. I just hope everyone at Mircosoft is still there. I would feel really bad if an aquiantence of my there had reprocussions. We would need to find a way to help them out, if they took it on the chin for us.

http://oss.sgi.com/projects/kdb/download/ix86/ contains a patch for kdb v1.5 against 2.4.0-test9-pre8.

Changes from kdb v1.5-beta2.

• Upgrade to 2.4.0-test9-pre8.
• Fix premature NMI oops on machines with large numbers of cpus.

This version of kdb also includes :-

• NMI oopser for uniprocessors. This builds on Keir Fraser's excellent patch for activating the local APIC on P6 systems and (ab)uses the local APIC to generate NMI on systems which have a local APIC but no IO-APIC, typically any P6 and above uniprocessor. So you poor developers with uniprocessors can now get diagnostics when the system gets into a spin loop.

  On the Processor configuration menu, select 'APIC and IO-APIC support on uniprocessors'. That option will detect the local APIC if it exists. See the help for 'NMI watchdog active for uniprocessors' and Documentation/nmi_watchdog.txt.

Expect the configuration method and the use of /proc/sys/kernel/nmi_watchdog to change in future. Ingo Molnar and I are discussing how much of the NMI oopser for uniprocessors should go into the standard kernel.