Linux: 2.5.40-ac1

Submitted by nimrod
on October 3, 2002 - 7:07am

No, I am not hallucinating. Yesterday, Alan Cox [interview] released his first 2.5 -ac kernel, 2.5.40-ac1. Among other things, this new branch includes Alan's work on the aacraid scsi driver, support for the NCR Voyager architecture, and ucLinux (a patch to run linux without a MMU (Memory Management Unit).


['+' indicates stuff that went to Linus, 'o' stuff that has not]
From: Alan Cox
To: linux-kernel
Subject: Linux 2.5.40-ac1
Date: Wed, 2 Oct 2002 18:18:18 -0400 (EDT)

Linux 2.5.40-ac1

+	Initial port of aacraid driver to 2.5		(me)
+	vfat corruption fix				(Petr Vandrovec)
+	Clean up firestream warnings			(Francois Romieu)
+	Voyager support					(James Bottomley)
+	Fix split_vma					(Hugh Dickins)
+	Fix config in video subdirectory		(John Levon)
+	Update olympic driver to 2.5			(Mike Phillips)
+	Fix sg init error				(Mike Anderson)
+	Fix Rules.make
o	Merge most of ucLinux stuff			(Greg Ungerer)
	| It needs putting somewhere so we can pick over the
	| hard bits left
	| Q: Wouldn't drivers/char/mem-nommu.c be better
	| Q: How to do the procfs stuff tidily
	| Q: Wouldn't it be nicer to move all mm or mmnommu specific ksyms
	|    int the relevant mm/*.c file area instead of kernel/ksyms
	| Q: Why ifdef out overcommit -  its even easier to account on 
	|    MMUless and useful info
+	Stick tulip back under 10/100 ethernet		(me)
+	Correct docs for IBM touchpad back to how	(me)
	they were before
o	Fix abuse of set_bit in winbond-840		(me)
+	Fix abuse of set_bit in atp			(me)

--
	"When Dilbert has a better working environment than you
			its time to leave"
				- Anonymous

From: Greg Ungerer To: linux-kernel Subject: Re: Linux 2.5.40-ac1 Date: Thu, 03 Oct 2002 09:38:11 +1000 Hi Alan, > Linux 2.5.40-ac1 [snip] > o Merge most of ucLinux stuff (Greg Ungerer) Woohoo! > | It needs putting somewhere so we can pick over the > | hard bits left > | Q: Wouldn't drivers/char/mem-nommu.c be better OK, that is easy to do... > | Q: How to do the procfs stuff tidily Yes. I need to spend some time on this one. Just lots of little differences... > | Q: Wouldn't it be nicer to move all mm or mmnommu specific ksyms > | int the relevant mm/*.c file area instead of kernel/ksyms OK, I have a new patch today that cleans all this up. I made all the existing ksysms symbols present. It turns out many where already there in my more recent patches anyway. A couple needed to be stubbed. The next patch has no diffs to ksyms at all. > | Q: Why ifdef out overcommit - its even easier to account on > | MMUless and useful info I was looking over this yesterday too. Should be able to clean this up a bit. What do you think about the separate mm/mmnommu directories at the top level? Should the mmnommu be merged into mm? Do you want me to CC you when I put new patches up? Thanks Greg

Related links:

Clueless

on
October 3, 2002 - 12:08pm

Thought I couldn't trust my eyes either. I wonder why he did it. Had davej not come back with -dj I would've understood, but now I'm completely clueless.
And as always he's putting out patches like a maniac, too. 2.5.40-ac2 has already been released.

Re: Clueless

Anonymous
on
October 3, 2002 - 12:44pm

I guess he's back at it because the IDE layer is back into a sane state. I think it was his major gripe with 2.5 development. I might be wrong though.

-- Paulo

Re: Clueless

on
October 3, 2002 - 12:56pm

Makes sense

Re: Clueless

Anonymous
on
October 3, 2002 - 1:19pm

We can only guess. I haven't see anything on LKML from ac that says the IDE is in sane. But I continue see bug reports on IDE-SCSI. If Jeremy would do an interview with Andre, ac, Jens? Then we will would know more :)

please don't interview andre

Anonymous
on
October 3, 2002 - 11:43pm

The guy can't write two words without making an ass out of himself. Try reading his patch descriptions and mailing list responses sometime, especially the ones where he has to deal with others' opinions of things - he is not an easy guy to work with. Thank god Alan is willing to restrain himself enough to manage Andre's work - which admittedly adds good features. If Andre were a little more socially tolerable, there never would have been a problem with the ide layer in 2.5 - Linus just couldn't stand the guy. An interview with him would not be productive or informative.

interview Alan

on
October 4, 2002 - 7:21am

If we want to know why Alan has started with 2.5ac then we should ask him directly.

Re: please don't interview andre

on
October 4, 2002 - 1:05pm

I agree with you on most of Andre's mails on lkml, but maybe we can find out better if hear some more words from him. I also got the impression that recently he turned down his tone a little bit. Maybe he learned his lesson or at least he started to - hopefully ...

It could also partly be language

Anonymous
on
October 4, 2002 - 6:29pm

I had a friend in college who was a bit brash, but mostly he was just energetic and fairly excitable. He also didn't have much tact, preferring just to say what's on his mind and tell things as he saw him. I personally thought he was an ok guy, but many people just thought he was a moronic arse. His problem communicating with many people was a deep lack of command of english, especially its subtleties. Since his first language was Spanish (coming from Colombia), that's understandable.

The combination of barely comprehensible english, lack of body language queues to distinguish a jab from a ribbing, and the clash of egos between people who otherwise know what they're talking about leads to some pretty stark breakdowns of communication. The main problem is that when people read incomprehensible english, they tend to immediately discount the author's intelligence level (at least subconsciously), even if they know the author is intelligent. Etc... etc... etc..

If you've read any of Andre's emails, you can tell english isn't his first language. (At least, I'd hope it isn't after seeing some of the barely coherent and tortured locutions in some of his emails.) Unfortunately, I think it tends to be an impediment to him getting his point across without him coming across as a jackass. He says something once, people don't understand him, he says it louder (rather than more clearly)--wash, rinse, repeat.

feature freeze

Anonymous
on
October 3, 2002 - 1:56pm

It could also be that he want's to get all this stuff tested by people so that it be easy enough to get it into the 2.5 kernel before the feature freeze at the end of this month :)

2.5.40-ac3

on
October 4, 2002 - 1:42pm

> And as always he's putting out patches like a maniac, too.
> 2.5.40-ac2 has already been released.

A maniac indeed. and -ac3 is already out. You gotta wonder how he keeps up with everything. And he doesn't even use BK, AFAIK.

Efficiency

Anonymous
on
October 4, 2002 - 2:38pm

And he doesn't even use BK, AFAIK

Believe it or not, some people can actually hack code and merge patches faster without a silly proprietary source control program to get in the way.

NPTL?

Anonymous
on
October 4, 2002 - 2:30pm

Any idea if/when NPTL will be merged into 2.5? Looks like it could make Mozilla and Apache 2 fly.

No it won't

Anonymous
on
October 4, 2002 - 11:29pm

To start with NPTL is a thread library which is used by userspace programs - it just translates the kernel's thread API into POSIX thread API, the kernel APIs and improvements you've been reading about are used by it.

Second, Mozilla isn't slow because the thread implementation is slow, and the current thread implementation (libc pthreads) is not exactly a slug anyway. The only time you'll notice any difference is creating / deleting / context switching huge numbers of threads and they'll improve if they do lots of locking, so apache 2 will speed up a bit, a few percent maybe.

Couple rebuttle points

Anonymous
on
October 5, 2002 - 1:16am

FWIW, to support NPTL, there were many kernel changes Ingo had to make. I believe most of these are in. (Things like O(1) scheduler, O(1) exit, futex fixups, getpid fixups, etc.) So, if any of Ingo's NPTL-related kernel changes are still pending, I'd like to see these get in in some form or another.

Second, stock pthreads (eg. GNU Pth) is a cooperative multithreading environment. This means if one thread blocks, it stops the whole process. Unless you're using NGPT with MAXTHREADPERCPU > 1, you're stuck with a single native thread and a one-stall-all-stall model. Now, I believe the LinuxThreads version is better than that, with a 1:1 model between the threads in the process and native threads. Given that, it shouldn't be quite as bad. So yes, you're right, Moz and Apache won't see a huge difference. (Moz -- almost nothing, Apache, maybe a couple % on a machine with over 100 threads.)

The biggest thing that'll speed up Mozilla and applications like it is prelinking. Someone else here pointed out prelinking. Jakub Jelenik at RedHat's been doing some work on it. The two most exciting things about it are:


  1. Reduces startup time because no relocation work is done at load time. Tests w/ Konquerer show a 1/2 second reduction in time from starting the command to getting to main. (Basically, from 0.51 seconds down to 0.01 seconds.)
  2. Because load time has no reloc's, you end up with a lot more shared pages and MANY fewer COW pages. This is very important when considered across many apps that share libraries. In an enviroment like GNOME or KDE, a single app could link a dozen or more libraries, nearly all of which are shared with nearly all of the rest of the environment.

Thus, prelinking stands to make desktops such as GNOME or KDE and programs such as Mozilla much faster. It'll be a much bigger difference than NPTL.

GNU Pth is _not_ used in glibc on Linux

Anonymous
on
October 5, 2002 - 7:14am

AFAIK, glibc provides a pthread POSIX 1003.1c API. On Linux it's a 1:1 threading model since it uses the clone system call; it was implemented by Xavier Leroy way back in 1996 and used to be called the LinuxThreads library, it got merged into glibc 2 later on.
GNU Pth [i.e The GNU Portable Threads by Ralf S. Engelschall] is indeed a userland thread implementation thing which run on various Unices, Linux is among them.

By the way, glibc 2.3 got just released. ELF's prelinking support is there which should reduces significantly startup times for some applications.

prelinking...

on
October 5, 2002 - 9:28am

GNOME?
Isn't slow prelinking an exclusively C++ problem?

Mozilla and the bigger KDE apps have always suffered from it.
I never read up on it much though...

Not just a C++ problem

Anonymous
on
October 5, 2002 - 6:08pm

It shows up worse in C++, because of all the Vtables and such. Thus, a C++ program with lots of virtual methods could end up with a far worse problem than a C program that just has to resolve some function calls.

In general, though, all unresolved symbols need to be patched at link time, which for dynamic linking means run time. Patching unresolved symbols results in dirty pages, and thus you take a COW overhead at run time and you carry extra, non-sharable library pages.

bug report

on
October 9, 2002 - 12:31pm

Where should I submit a bug report? Back at around ac3 for 2.5.40, 2.5 ac kernels stopped booting on my system.

I have an SMP system and it gets to a point while attempting to boot where it says something like:

CPU1 is now up. (or this part might be CPU0)
Starting migration thread to CPU1
(I think I remember this line 100% corect or at least 95% correct and this is the last line I'll get and then the system just stops here).

However, 2.5.40-linus and 2.5.41-linus will boot fine on my system. 2.5.41-ac1 still has this problem on my system.

So where does one submit ac bug reports? :)

-Cameron

re: bug report

on
October 9, 2002 - 12:47pm

You should read this FAQ: http://www.tux.org/lkml/

It includes info on posting bug reports to the lkml...

well

on
October 9, 2002 - 4:08pm

Well,

That's great but I wasn't sure if lkml was the place to do it, I figured that was mainly for -linus

But I'll give it a shot.

Thanks.

re: well

on
October 9, 2002 - 7:08pm

The lkml would be the appropriate place, after reading the above FAQ.

However, notice that Alan says, "This is basically about making it compile. I've not tried to tackle the second problem of testing it all yet." He's said this about both Linux 2.5.41-ac1 and today's Linux 2.5.41-ac2. So, perhaps it's not all that surprising it doesn't work for you... ;)

ac2

on
October 10, 2002 - 12:10am

ac2 works in that it boots, but OSS (open source system) support is still broken, have to use alsa.

Maybe I'll still submit a report but right now I'm happy as a clam, my desktop is noticably faster, not a HUGE difference, but one to make me want to attempt a 2.5 kernel full time (not like I'm a newbie or runnning a server :)).

I'm not getting any sound through alsa but that might be my fault, I've gotten sick of all my mp3's and CD's so I haven't spent much time with it.

Thanks again though.

-Cameron

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.