Slashdot Mirror
MontaVista Rolls Out Fully Preemptable Linux
A couple people wrote with a link to an article about MontaVista. They've introduced "a fully preempetable Linux". It's based on kernel 2.4, but the timing is interesting, considering 2.4 isn't completed yet - and if this had come out earlier, perhaps some of this could have been included. The article's a bit press releasely, but has some good info.
Why are all of these companies switching to the 2.4 series of kernels? I mean, do they know something the rest of us don't? I'm aware that most of the Linux users out there probably do have a box running a 2.4 series kernel, but I wonder how many of us are willing to actually trade of the security of a tested 2.2 series kernel for these performance enhancements...
"Life ain't interesting till you blow something up" --Anonymous
A fully real-time linux that could support Rate monotic analysis is EXACTLY what the real-time world needs. Reliance on expensive, proprietary Realtime OSes prevents many small companies from entering the real-time world (I used to work for one - a license for QNX and a compiler was about $5000 US and it was the cheapest. Of course, prices have come down :-)
-- Rich
Free your mind and your Ass will follow -- George Clinton
Perhaps it is slashdottal for something which can preempt...
"MontaVista would like to see this technology, or similar technology, utilized as a foundational feature of Linux 2.5 ... Linus indicated that he is leaning towards a fully preemptable kernel approach in Linux 2.5."
For a company that claims to be revolutionizing Linux kernel development (I assume it's them making the claims, considering this sounds more like a press release than a news report) -- shouldn't they know that the next version of Linux is 2.6, not 2.5?
Cheers,
IT
Power corrupts. PowerPoint corrupts absolutely.
I am currently a user of QNX OS and it's preemptive real-time capabilities are absolutely astonishing. For the sake of Linux I would hope that this company holds off on production of its distribution until the kernel is at least stable, if not fully released. If a big "oops" is made too early in the game, many people or just going to stay with their OS of choice, which isn't at the time most likely Linux, because having confidence in what OS you stick on your real-time hardware is no laughing matter at all.
This article points out an area in which Linux has one major weakness over traditionally developed operating systems such as Windows, Solaris or even BeOS, and that is that essentially one man has control over the entire operating system, and it is his somewhat capricious wishes that govern the addition of new features and the acceptance of patches.
Whilst I'm sure Linus Torvaldes is a competent, possibly even brilliant programmer, his quirks make the entire project too reliant upon him - his disdain for CVS springs to mind as an important example. Were he to be hit by a bus tomorrow then development would be stunted as people like Alan and Inigo fight over the "hot seat", and the open source movement would fail without Linux.
What Linux needs is to be incorporated under law as a non-profit organisation which can then be run by Linus at CEO/CTO. This way they can implement a professional approach to things like source code control, copyright and trademark infringements, and reviewing new proposals for the kernel, like the one rejected by Linus for specific preemption points.
Unless this happens, the Linux operating system is left vulnerable, and if its creator should leave for any reason, its progress would most likely shudder to a halt.
---
Jon E. Erikson
Jon Erikson, IT guru
This was discussed on the kernel mailing list a few months ago (before MontaVista did their implementation of it) and it seems likely that a preemptable kernel will be available (or the default) in Linux 2.5 for _uniprocessor_ systems .
The problem, though, is that the approach taken doesn't work on multi-CPU systems. The overhead of synchronization between CPUs is prohibitive when doing preemption in the manner that MontaVista describes.
This show the power of open source. These guys proposal was regeted so they decided to add in themselves. If they improvments are good enough it will be incorparted in the next version of linux. Got to love it.
Somebody has to be first.
In Antartica, when the penguins are ready for a swim to go get some yummy fishies, they all cluster around the edge of the ice. No penguin wants to be the first one in, because there might be penguin-eating seals in the water. If only some brave penguin would jump in first, then they could watch to see if he suddenly turns into a bloody chunky cloud in the water.
I guess Montavista is one of the brave penguins.
Basing their code on 2.2 would mean it was outdated before it was of any use - afaik 2.4 has big extra support for SMP, which is essential for their pre-emptive solution.
It's not as though 2.4's contents are unknown, they have probably been working with 2.3 builds all the way through. they mention they have been in contact with linus torvalds, i'm sure that for something this big he would have provided them with as much information about 2.4 as soon as possible.
Integration into 2.5 makes sense, not 2.6, so this can be tested and refined within the full linux kernel development environment, and then subsequently released into 2.6 as part of the full stable kernel.
i really look forward to this, this is _good_ corporate involvement with useful goals.
fross
...if this had come out earlier, perhaps some of this could have been included [in kernel 2.4] 2.4's already taken so much longer than any other release, why not just slap on a few more months to integrate preemtion?
"MontaVista's Hard Hat Linux distribution"
HARD HAT? Make me say uggghh! uuggghh!!!!!
Gee, Even PinkHat sounds better.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
Now other projects, like GNOME, are gaining a 'critical mass' of interest from developers and industry. I expect progress will be made by leaps and bounds.
The future looks bright.
> Can someone explain what difficulties these people at MontaVista must have overcome? What is
> it about the linux we know that makes it not fully preemptable?
Current Linux only switches processes when the kernel explicitly decides to. (in other words, when a system call finishes all its work, or when a system call decides that work will take so long that it is time to give another process a chance to run)
This patch makes Linux able to switch between processes every time that an interrupt hits, even if it is in the middle of a system call.
The trick is to avoid deadlocks. Consider the following case: process A enters a system call, and the system call takes a lock. Then, an interrupt hits and process B is scheduled, preempting A. Now B does a different system call. This call disables interrupts and tries to take the same lock. It can't get it, though, because process A already has it. But since interrupts are disabled, process A will never get a chance to run again.
Your machine hangs hard.
The solution to this problem chosen by MontaVista is to simply disable all preemption whenever _any_ lock is taken by the kernel. The disadvantage to this approach is that:
- even when it is not possible for a set of locks to conflict, preemption will still be disabled.
- all locks become slightly slower (because every lock operation must now disable preemption too)
There's also a story about their scheduler...
Linux doesn't belong to "the community", it belongs to Linus. He can run it how he wants. If you don't like that, feel free to issue the following command:
/usr/src/linux /usr/src/Jonix
cp -a
You can then incorporate or whatever the heck you want. Remember to abide by the GPL and good day.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
I know what preempting is, but I don't understand what makes something "fully preemptive". Why is "fully preemptive" better than, er, I guess, "partially preemptive", and what do these terms mean? Anyone care to elaborate? What will be gained by making the kernel "fully preemptive", and what state is the kernel in now that keeps it from being "fully preemptive"?
Well I can't claim to be an expert kernel hacker, but I have had to use Linux for what was essentially real time interactivity, relying on controlled conditions to provide me with CLOSE ENOUGH. The fact that Linux IS reliable and predictable and has been for some time, has allowed alot of folks to use it as if it was a fully multitasking system, and in many ways that sort of quality of service (having programs not freeze because of other programs) is what I think
drew me to Linux in the first place.
For a time I explored BeOS and the BeBox in particular, but the slowness of that development and the abandonment of the hardware left me cold. Still it had some interesting ability that other OS's don't have involving streaming media, and anything that brings such things (Rendering in a window continuing smoothly while window was being dragged as one example) is a good thing for the user community as well as for the embedded.
While people DO seem to throw alot of hardware at problems to make operations smooth, with my Athlon 500 and 256 ram I cannot run an IE 5 session without getting skips out of winamp. This sort of performance depresses me so much I have already begun to switch over to Linux on the machine for normal use, despite it being purchased for windows development (necessary evil).
I don't know how long it will take to get this sort of performance up, and I know that the danger of RTOS functions is that a badly programmed high priority thread can cause havoc, but if there were proper guards against such things, it would probably be enough to make Linux my OS of choice for interactive exhibits (which it is close to being as it stands).
As to why we are already talking about 2.4, what I really want to know is why 2.5 is meaningful, when it is an unstable track and thus unlikely to be seen until 2.6 in most desktops. What does this mean? If we are talking about something that is done now that is not going to be in a stable release for another year, but with 10 and 100 fold improvements, does that mean we are going to have to start supporting development kernel releases for clients because the feature set is too important to miss? It hasn't been the case for me since 1.3.. I really DON'T want to be doing kernel catchup in the modern era.
If this is important technology, then why can't we postpone 2.4 a little and move it in?
What kinds of schedules are we really talking about?
Is 2.4 expected this week? Is this RT stuff expected this year?
Unlike with Windows and Mac, I don't think that many people are sitting on the edge of their seat waiting for 2.4. I don't think it is keeping folks from choosing Linux. I am not sure I can understand the purpose of rushing forward if there is good technology that can become PART of the mainstream kernel without causing radical change in usage.
Or is this not so important after all?
Ingo did a preliminary patch for this a while ago, as part of his low-latency work. It appears that MontaVista has picked up the ball and run with it. Integrating a patch like this is going to require a lot of QA, so it should go in early in the 2.5 cycle -- this is definitely not something that one throws in at the last minute.
:-/ Anybody have a good reference to lockless data structure, algorithm, and design techniques?
It will be interesting to see how much the preemption infrastructure impacts performance (throughput) on a uniprocessor.
On a perhaps related note, I've been thinking about the growth of locks in the kernel. Many of these will have little contention, and locking is a pessimistic approach that incurs overhead. Plus, more locks means more locking discipline required.
Nothing has been "rolled out". This is not a product launch. This is the prototype release of preliminary code for a development kernel. The 2.4.x series isn't here yet, and neither is MontaVista's code.
Read the article, as there are several paragraphs in there talking about where this code will be going. They're hoping to get it incorporated into 2.5.x NOT 2.4.x.
Francis Hwang
Do domain names matter?
I think that should read, "one trick among many tricks is how to avoid deadlocks".
To have decent real-time performance, they need to:
- Optimize interrupt handling code so that drivers get out of the handlers and into preemptible threads as quickly as possible;
- Find an efficient synchronization mechanism for dealing with multi-processor system lock issues;
- Deal with the priority inversion problem, which happens when a low-priority thread has control of a resource needed by a ready-to-preempt high-priority thread;
- Optimize the scheduler
None of these problems are new, they're just a pain, particularly when you're trying to wedge them into a kernel that wasn't really written with these things in mind from the start.> At the very least, the final say on all things
..fork the code, but this wouldn't be of
..
> to do with the kernel should be handed to Alan
> Cox,
Hmm. a few things spring to mind..
Don't you think Alan should have some say in what "should be handed to" him? The last I heard, he wasn't terribly happy that he was even seen as second in command, never mind first.
You don't think Linus should be in charge, but what makes you think others would be happy if someone else were?
The only reason Linus is still in charge is because he is bloody good at his job. Do you really believe Linux would have got this far if he weren't?
>
> benefit to the vast majority of Linux users
It would if it was better. Do you really think anyone would hold back on forking the code if they thought they could do a better job than Linus? I know I wouldn't
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
I like the sound of it.
:)
While I generally prefer FreeBSD, one of the reasons is exactly the desktop responsiveness spoken of. On the same machine, I find FreeBSD far more repsonsive than Linux when using X under load. On Linux, I can feel the lag in system response at a load of about 3--even though that load is from doubly niced makes and there's plenty of physical memory left. Under FreeBSD, I've gotten to loads of 10 without any noticable degradation in response.
NOw if anyone can find a way to quantify this . . .
As a rule, I avoid the comments on moderation. However, this morning I"ve noticed a cross a few threads that it seems to be a bad crack day. A couple of troll/flamebaits here, a couple more elsewhere.
Seems a couple of folks who drew moderation today took the "I am your God" comment a bit too literally, and must smite all unbelievers . . .
and push a penguin :)
Of course, the penguin that gets pushed gets the best herring.
Then again, the second mouse gets the cheese . . .
which reminds me, I better go check the traps in the attic. I could have four-day dead mice by now . . .
Is-it 2.2 or 2.4 ?
The 2.4 will include some code to make the kernel more "responsive", but I suspect that this will be true only for "soft-real-time" processes (audio application).
I'm wondering if the desktop responviness will be better under 2.4..
May be, you could try using XFree86 4.x if you have a supported card, I suspect that it would help more than a new kernel release..
Are you using KDE, if yes KDE 2.0 should help..
The nicest thing about all of this is that even if Linus rejects MontaVista's changes, there's nothing stopping anyone who wants to use those patches from getting the code. While it's true that Linus owns the Linux(tm), the truth is that we all own the code, by virtue of the GPL, and we can all do what we want to with our own copies, whether Linus approves or not.
Contrast this with a non-GPL work, where if a single marketdroid decides to quit selling it (even if it is a good product), all the product's users are permanently and irrevocably screwed.
People can bitch all they want about the GPL, but it is clearly working to everyone's advantage here. Thanks, RMS!
b.g.
b.g.
MontaVista, recall, is an embedded linux company. Since embedded systems don't need SMP, that's not where their focus is. It'll be interesting to see if they try to add support and what actually gets into the official kernel.
Btw, I happen to work at MontaVista Software (not their main office right now, which is why I'm kinda' out of the loop and don't have more to say about this), and can attest that they're really cool folks! <grin>.
PhuX0red, or perhaps some of the components (video card/sound card) aren't as up to date as the processor.
... I'd presume it's the same problem, and not IE5's fault. If it turns out not to be, I'd agree with
This is covered in the Winamp FAQ and/or help file (last time I checked), about why the music skips when someone scrolls in a window, etc
you on the phuX0red diagnosis.
But hey, it's always easiest to blame microsoft, right?
Ahh! Now I remember. He is the meanest kernel bandit in Mexico. :-)
${YEAR+1} is going to be the year of Linux on the desktop!
...even most people who think they do.
With CPU speeds being what they are today (and constantly increasing), the number of cases in which the regular schedular can't handle things correctly is really very low.
On the other hand, some of the improvements done for RT purposes (eg. finer-grained locking) help other people too (eg. SMP users).
I guess Linux isn't a 'time sharing' system any longer.
Has the 'nice' command been disabled? What happens when User 27 on the teletype down in the basement of the Physics building is plonking away at the keyboard and the response locks up for ten seconds? Do we really want User 18 up in the third floor of Mace Hall to be able to lock up the whole system to run that data acquistion program?
Sounds like there's some cool potential for DOS attacks here.
The rep Ready Systems had some years ago with people buying real time systems is that if it visibly works in the demo, it will probably work in the product you buy. If the salesdroid talks about it working, it won't. Perhaps that's just in the Southeast US, but their reputation where I work was far from enviable.
In VxWorks one of the things we learned to do early was get the hell out of interrupt level as quick as you could. The driver I ported to VxWorks for an FDDI board, for example, basically shuffled stuff onto a ring buffer that fed the process (at high priority task level) that did the actual work. That's because interrupt level was honest-to-god interrupt level.
Please forgive my ignorance here, but is that the way people are writing Linux drivers? If not, then you're going to have a massive job of driver rewriting before preemption is actually usable for (e.g.,) cyclic schedulers like we use in training simulators and some kinds of hardware-in-the-loop simulations.
Simply turning off preemption every time a process or a driver takes a lock is a far, far cry from usable preemptive scheduling. If I need a 60 Hz scheduling event, then I bloody well need it at 60 Hz, and a pause for a few dozen milliseconds for a filesystem sync (etc., etc.) is right out.
And there was a need for a number of parallel utilities in VxWorks. For example, printf() takes a semaphore, so it's unusable at interrupt level and you have to use another function to print things out at interrupt level. Note the way VxWorks did it: it doesn't let you take a semaphore at interrupt level, which is just the opposite of what Ready is suggesting. Why? Because they believe real-time is important, and it's at the core of the philosophy behind the operating system, not an add-on.
Unless I've badly misunderstood this, it looks like preemption in Linux is going to be a toy.
It also sounds like this code might be a much better variety of what was originally proposed for 2.4.
Anyway, Linux only has a few years of development left. The system we run 10 years from now will be Free Software and will contain a lot of the same tools, but might well have a different kernel. I'm surprised that people don't consider this more.
Thanks
Bruce
Bruce Perens.
do you think there is any chance of Montavista's kernel dominating Linus's kernel. Making it effectively the standard instead of Linus's. Same question but to their distrobution?
Fork!
Fork! Fork! Fork!
Yay!!!!
(should we dub the new project OSF II ??)
Let's form committees!!!
RMS's loss would cut the heart out of the free software movement
HAHAHAHAHA!
I'm not even convinced he played a significant role in any major trend except promoting the TLAs: FSF, GNU, GPL, and RMS. That, and injecting a lot of moralistic nonsense into what are essentially economic and engineering issues.
Free software is not like free speech. It is like public domain text: nice to have, but not a fundamental property of a free society. Going around convincing people that it is essential is harmful both to them and to the people who have rational reasons for releasing free software.
If he was never born, the major difference would be that Emacs wouldn't be around. If he died today, nothing would really change. He hasn't really done anything significant in a long time, he just goes around as a figurehead of the "free software movement" who is hated by half of the people involved in free software.
--------
2.5 is right
they want to get the code into the DEVELOPMENT kernel.
Trying to get something like this into a stable kernel would be overkill. Something like this would be best put in early into the next devel kernel (2.5)
Luke
I've just been dabbling into the excellent RTL/RTAI work done. I'm using the Lineo (formerly Zentropix) distro. This candidate stuff for 2.5 - would that render these pointless? What's the difference between the two approaches?
One man's pink plane is another man's blue plane.
This was in kernel traffic either last week or the week before. I think that it was not added cause it was either alot of changes or it was messy code. I think also that Linus has his wants and not wants in the kernel.
I wonder if this is the start of the forking of Linux that so many have said woudl happen. May the best kernle win.
I also wonder if they are releasing there changes to the kernle as Open Source under the GPL? ;-)
~~~~~~~~~~~~~~~~~~~~
I don't want a lot, I just want it all
Flame away, I have a hose!
Only 'flamers' flame!
It's "hard" real-time, but is it deterministic? A little history: Jim Ready, MontaVista's Realtime "pioneer" gave us VRTX. It was not deterministic, which gave pSOS an entree. The VRTX people responeded with VRTX32.
> But if this is done, it wouldn't be fully preemptable, would it?
It's not really "fully" preemptible.
No OS can be fully preemptible, as long as there exist drivers which require atomic access to hardware. Any such device will require interrupts to remain disabled (as well as preemption) while hardware access is ongoing.
The simple way to get an idea of the difference is this:
;-), and hats off for the developers!
- Linux does fully preemptive multitasking, which means that CPU time is shared by multiple processes, that each process gets his part, and that if some process waits (e.g. for I/O), his "part" will be used to run other processes in. So all in all, this is a fine "time-sharing system".
- The kernel however, doesn't do this internally (yet!). If you do a kernel call, e.g. write to a device, the kernel call is the _only_ thing that runs at that moment. If it has to wait for something, it just _waits_. Only after the call has returned, Linux starts looking at the scheduling system again.
A fully preemptive kernel means (anyway in this context), that it is also preemptive internally, so if kernel code has to wait for something, other tasks can be performed. As you might understand, a fully preemptive kernel must be _very_ sophisticated. I'm glad we're gonna get it (well, if Linus permits it, anyway
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Is that we used to love Linus, but now it's mostly just a habit?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Forget about Linus being hit by a bus. It's not going to happen. Public transportation in the Seattle area is mostly trains. As long as Linus stays away from rails, we're ok.
What we really need to worry about is Linus being hit by the Slashdot Cruiser.
I realize, of course, that the Cruiser does not have sufficient horsepower or vehicle weight to actually kill Mr. Torvalds. Nevertheless, the experience could leave him severely injured and traumatized.
Imagine how you would feel if you were crossing the street and saw that green automotive embarrassment bearing down on you. It would be horrifying and you would probably be petrified. Unable to dodge the oncoming plymouth, you would be struck at knee-level by an overweighted green go-kart. The personalized plates would undoubtedly leave an "1m 1337" impression in your shin.
Clearly, the experience would leave Linus unable to write code effectively. He would be unable to follow the development newsgroups because of involuntary twitches every time he sees "1337".
For the sake of Linus, Linux, the Olsen Twins, and the Fee Software Revolution (tm), I think our course of action is clear: We must dump the Cruiser into the lake. It's the only way.
Got a full tank of hot grits and a penis bird in the glove box.
The SMP support already allows multiple processors to execute much of the kernel code already, except within locks. In principle, any code that is not in a lock and runs on SMP can be made preemptible on a single processor. So this is not a hugely revolutionary step, but rather evolutionary.
I'm glad that someone is taking the effort to actually do this.
"MontaVista would like to see this technology, or similar technology, utilized as a foundational feature of Linux 2.5,"
2.5? 2.5 will be an UNSTABLE release, these guys obviously don't have a clue what they're talking about... 2.4 isn't even done, and now they want entirely new technology to be part of a kernel version that by its very nature will be unstable? I don't think so!
The BSDL doesn't require changes to the licensed work to be subsequently released in source form. So, Monta Vista could legally make similar changes to FreeBSD and keep the source code all to itself.
So what I'm talking about *is* GPL-specific, and the ignorance of the common man is *exactly* the reason why we need the FSF.
b.g.
b.g.
So - if MontaVista's kernel is fully preemptive it should be interruptible at any time. This means that there are no times when you can't serve an interrupt, or am I wrong? Therefore, doesn't this throw up problems for atomicity? What if I read the value of A into a register, then an interrupt occurs which reads the value of A, modifies some hardware settings, then changes the value of A, the interrupt returns, then I look at the value I have in the register and on that basis, I modify the hardware settings again? This is the classic problem, where atoms are required, and one standard solution is to use atomic CPU instructions which read, test and modify A in one instruction. But my question is, how are these kind of atoms implemented on platforms which don't support these kind of instructions? (Amiga, for eg., off the top of my head)
You go on with your bad self. Because hey commitees are soooo much better then an informed individual. We can get a committee of people who can agree and are idiots and then start with the five year plans. THat's a great idea.
Linus killed it because it was a fucking dumb idea. No other reason. He doesn't have to accept anything. He even freely admits that his job is to keep crap out of the kernel more so then writing code.
- Why is the ninja... so deadly?
On the other hand, yes, they would be able to distribute a closed binary based on FreeBSD. So what? They suffer from increased merging cost, decreased popularity, decreased peer review, and more expensive development. So really only stupid programmers wouldn't release back in that scenario, and try to take FreeBSD "head-on". Are you afraid of stupid programmers?
The GPL thrives on the delusion that someone who programs for a living (or their bosses, etc) is a monopolistic idiot that can't embrace open source. That's not true; release back the majority of your changes, and if you must, hold on to that 1% that gives you the definite advantage to your competitors.
-bugg
... out of seeing the handful of posts NIT-PICKING the numeric versioning system thing.
And, since I haven't posted here for awhile, and so dislike people who nit-pick an issue simply to look intelligent, allow me to take the very same sentance and explain it to you:
"MontaVista would like to see this technology, or similar technology, utilized as a foundational feature of Linux 2.5,"
"... this technology, or similar technology", referring to the preemptive structure changes and coding they have been working on. Very cool, and I think everyone can follow it this far.
"... utilized as a foundational feature", meaning they would like to see these largish to major changes made early on, either all theirs, part theirs, worked on by them, others, or a better way, whatever works out to be the Best Thing for Linux. Again, seems fairly clear to me.
"... of Linux 2.5", meaning they would like to see it begin incorporation in Linux 2.5. This seems proper to me.
As I see it, it was stated correctly, a new, and fundamentally large change such as this would be inculded in a DEVELOPMENT kernel. Hence, the term DEVELOPMENT.
A large change like this would NOT get directly incorporated into a STABLE kernel series.
You're beef seems to be more of a grammatical one than anything else. Would Montavista stating it this way have satisfied you - "MontaVista would like to see this technology, or similar technology, utilized as a foundational feature at the beginning of Linux 2.5,"? Probably not.
Long ago, I read the explanation of the versioning system being used in Linux, and understood it. And ever since, I've gotten a chuckle out of anal-retentive grammatical nazi Slashdotters like yourself who feel the need to try and show the world that they know it too.
Get over it.
And now that I'm guilty of doing the exact same thing I so dislike here, I'm moving on before I end up conditioning myself to be guilty of it more often.
WTF are you talking about?
Got a full tank of hot grits and a penis bird in the glove box.
Get some decent hardware - my P2 450 doesnt have such problems
I see you've tried 2.4.. on what hardware setup? 2.4.0-test6 on my K6-III 400 w/ 128 mb of ram produces a very noticeably different behaviour under load (as compared to 2.2.16 and 2.2.17).
:)
For me, the difference was that make -j 27 (which help get a ludicrous load) didn't destroy interactiveness. I was able to type, etc, as if nothing else was happening on the system. This partially has to do with the atomic timeslice going from 200ms to 50ms, and partially from the general updates to 2.4. If you've not tried -test6, I suggest you do
--
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
This is a RTOS that could use a lot of help for its i386 port. That port is currently still in beta. The other ports for AEB, ARM, MIPS, etc.... are much more stable and usable. Plus, RedHat is introducing the EL/IX layer for Linux application compatibility.
Definitely check it out if you're interested in something that is free and opensource.
eCos RTOS Project Page
Red Hat eCos Product Page
---- "It is never too late to give up our prejudices." --Henry David Thoreau(1817-1862)
I'm trying to install this kernel patch, and I'm having problems. I've tried
/usr/src/linux directory, and it cannot find what it's supposed to patch. I admit I'm an idiot who doesn't know how to use patch, so how does one go about sticking this thing in?
patch -p1 (lessthan redirect) preempt-rtsched-2.4.0-test6-1.1.patch
from the
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
The GPL doesn't force distribution of code. So MontaVista could have kept the Linux code to themself.
It *does* force disclosure if they "distribute" the product, i.e. offer it for sale. Which is what Jim Ready's former company (Microtec Research, Inc., vxworks RTOS) was all about.
So really only stupid programmers wouldn't release back in that scenario, and try to take FreeBSD "head-on".
It happens all the time in embedded systems work, albeit I haven't yet found any FreeBSD examples specifically. I do know of several companies who based their hardware on the "freely available" (i.e. OS-compatible license) and very popular RTOS, uC/OS, and at least one RTOS vendor redistributed uC/OS as its own code!
Yet the uC/OS authors and contributors saw not a penny for their work, and the rest of us didn't see any source code at all!
The GPL thrives on the delusion that someone who programs for a living (or their bosses, etc) is a monopolistic idiot that can't embrace open source.
But unfortunately, at the moment much (most?) software is being developed and released by those "monopolistic idiots" in exactly the fashion you describe. When was the last time you saw the source code for the engine controller in your car, for example?
The GPL protects "us" from "them": by Linus' releasing of Linux as GPL, "monopolistic idiots" (we both agree they're out there) can't abscond with the Linux source code, enhanced or otherwise, whether Linus gets hit by a bus or not. For once, the sharks are on our side!
BSDL et al can't claim that. So until the majority take a more enlightened view towards software licensing, there's the GPL.
b.g.
b.g.
The article mentioned IA32 , not IA64. In other words, what most people know as the x86 family, i.e. Pentium III, Athlon, whatever. And of course, as with everything else I've seen from MontaVista, it's 100% free and Open Source. The patches to the kernel are right there on the FTP site, so you should be able to modify it to work on other platforms.
David
120 character sigs suck. Make it 250.
- Can we have this extra feature in 2.4
- Why is 2.4 taking so long to come out?
Well 2.4 is in a feature freeze, currently in the test phase. Lets not even think of asking Linus to put feature X into it.All requested features/modifications need to go in the 2.5 list, for consideration and debate.
Meanwhile vendors can go on getting their distributions ready for 2.4. They have work to do on updates for new ppp, networking, usb, video updates (DRI), XFree86 4, Gnome, KDE-2, LVM, MD, ATA-66, Firewire, I2O, I2C,
You're kidding, right? Or are you really saying that we should put new, experimental, unstable features, such as the MontaVista patches, into the stable kernel series?
I'll try to answer/respond to the most significant questions and points made here. 1. 2.5 is the next "development kernel", and is clearly the right place to initiate a fundamental kernel change such as preemptability. 2.6 is the right place for commercial usage, obviously. 2. Preemptibility means the systems can and will stop a process running in kernel mode and switch to a higher priority newly executable process. For more, including specifics of what our prototype does and how we want to advance it...read our white paper! Here isn't the place to repeat those details. 3. We are not dogs, but after a few beers or missed shots on the pool table we do howl alot. 4. We actually did initial work on 2.2.14 but our primary goal is proving out this technology, providing to customers who may need it, and offering back as a technology for 2.5 (->2.6). Hence, 2.4 was and is the proper base, given that we think we can have production ready software early next year, "long after" 2.4 is cooked. We feel releasing a prototype on 2.4-test software is okay. 5. A preemptable kernel is not a rate monotonic scheduler! We also offer a scheduler that sits on top of (runs before) the standard Linux scheduler that does a good job of selecting/dispatching real-time processes very quickly and with fixed overhead. It's not rate monotonic, it's a simple priority driven scheduler. 6. I won't engage in arguing the pro's and con's of "one man's control of an OS". It is the way it is. MontaVista lives with it and is trying to work with it. We think a preemptible kernel design, leveraging the SMP locks, is a good next step for the Linux kernel and benefits all "market segments" (types of users). We want to prove it with real software, and this is our starting point. We are "releasing early, releasing often", amen. 7. "these guys proposal was regeted"...I reget to tell you that you misunderstand. What was "rejected" was a set of patches that injected preemption points, which is a fundamentally different technology than what we've implemented. We have not proposed or submitted anything as of yet, beyond making our current prototype available. 8. Fross, THANK YOU. 9. Inclusion in 2.4 is absurd, it's time for it to stabilize, finalize and start getting deployed. 10. Most of the systems that Hard Hat Linux get designed into aren't serving "multiple users". They are control oriented environments. In such environments, having a design ability to assure that high priority tasks get cycles very quickly, with assurance, and all the cycles they want until they are "done", is critical. We are trying to enable that capability. Superuser privileges usually protect real-time priorities from casual mis-use on multi-user systems. 11. RTAI and RTLinux are "sub-kernels" which provide a lower level multi-tasking environment, a small set of services (mostly around synchronization and passing data to/from higher level Linux processes), and which virtualize interrupt off/on operations in Linux. Basically, they provide a multi-threaded interrupt handling environment with better worst case interrupt off characteristics. There are limitations to such an environment. A preemptible Linux kernel attempts to improve PROCESS responsiveness in Linux proper (as opposed to attached a small underlying, separate multi-tasking environment). They are quite different. They are not in conflict, and even with excellent preemption performance, a system can still benefit from improved interrupt responsiveness via use of RTLinux. 12. MontaVista did not request/support the request for preemption point inclusion in Linux. The perspective of our real-time team is that preemption points are NOT a desirable long-term technology, and we don't support their inclusion in Linus's kernel. 13. Everything MontaVista develops on our own dime is released as GPL or LGPL software. Everything to date anyway, and we don't see that changing anytime soon. Even most of what we've been paid to develop user professional services has been GPL/LGPL licensed (with our customers approval of course), as it's turned out. We are dedicated to the values of open source. We're a Linux company for gosh sakes! 14. Minimizing throughput impact on a uniprocessor is important. There are opportunities for throughput improvement under busy workloads...very simple workloads won't improve and could degrade, the questions are how much, and is the tradeoff worth it in order to get responsiveness/consistency of high priority behavior. Exploring, proving and educating in this area is an important component of our prototype work. 15. No our prototype doesn't yet support SMP. The cost of synchronizing across processors using the SMP locks shouldn't be more than synchronizing across processors using the SMP locks...don't know where you are coming from suggesting what we are doing will be prohibitively expensive on a multiprocessor! We'll share an SMP version when we get one put together (but it's not highest priority for us, our first order target for this thing is uniprocessors, which are far more prevalent in the embedded market segments.) 16. This is available for an IA32 platform. If you think that's an obscure platform...I guess you live in a parallel universe where Motorola hardware got selected by IBM back in the early 80's for their PC, or something! We'll productize on all supported MontaVista platforms (21 different boards across 4 different architectures as of our 2.1 release 2 weeks ago...). 17. I'm not aware Ingo did fully preemptable kernel work, and if Ingo did any work on such a system, we weren't aware of it and did not base this on any such work. 18. Preemptible is not interruptable. We've separately and previously done characterization work on interrupt off times in Linux. See our real-time project area on our web pages (www.mvista.com). Interrupt off times in Linux are surprisingly good, with one exception (child process exit with many children)...and of course ignoring arbitrary drivers that can misbehave. 19. Time to go howl... Sorry to be long winded. I hope this helps to clarify a few things. -Kevin
I did some testing on my old p2-350, and was able to get the system load up to ~13.5 (rc5, about 14 recursive finds in various xterms, a kernel compiling, X and netscrape running, etc..) before XMMS started to skip, as opposed to a load of 3-4 without doing it.
its off by default in case you run on broken hardware... if you have a reasonably recent (and reasonable quality) motherboard/ide controller play with unmaskirq and the other hdparm settings.. smash
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
I don't see relevance; most GPL and BSD-licensed work is not for embedded systems deep in an every day appliance.
-bugg
Why do I want the source for the engine controller in my car?
;^)]
:^)
:^)
Because it may contain code that you wrote, taken from something you posted under a BSD (or similar) license.
[But being the embedded hacker type, I can think of a lot more reasons, too!
It isn't so much the fact that someone might *take* my code that troubles me, it's that they may use it as a starting point for some kind of legitimate improvement, and then not give it *back*. They get rich, while the people who actually did the hard part, creating the code, get shafted.
I don't see relevance; most GPL and BSD-licensed work is not for embedded systems deep in an every day appliance.
Don't tell Lineo or Monta Vista that!
Deep embedded is *exactly* the market that they're shooting for. In fact, Lineo's marketing current marketing tagline is "Put Linux Anywhere".
And LinuxWorks used to be Lynx, a company that produced an embedded RTOS with a POSIX API, i.e. an embedded Linux lookalike targeted for deeply embedded systems (although it predates Linux by a number of years, I think).
The Day for embedded Linux is coming, if it isn't here already. I'm glad to see that it won't turn out like Jim Ready's previous company, where I had to pay >$10k for the priviledge of running his buggy, bloated and poorly documented RTOS, vxworks. On one product. Never again.
b.g.
I just noticed, we haven't mentioned Natalie Portman in this entire thread. Oops!
b.g.
I've *never* had my MP3 player skip on me in Linux. However it's not the point. The point is latency. You see, anyone can simply allocate a whoppin' big buffer and get rid of skips that way. It's easy, and it's the wrong solution.
Let's say I'm performing music live, using a sequencer and a software synth. If I hit a note on my keyboard, the software synth needs to respond to it and play that note. This needs to happen immediately, i.e. within milliseconds. A buffer does nothing for you here--you need to guarantee that the synth program geets a timeslice whenever it needs one, no matter what.
Your mp3 player doesn't need to respond immediately to any actions, so it can prebuffer as long as it needs to. Try adjusting the equalizer. Notice how long it takes for your changes to take effect? There's your prebuffering.
For true realtime performance--scientific and mission-critical applications, say, like targeting a brain tumor with a linear accelerator--you need hard realtime (i.e. microsecond latencies). This is provided by QNX and the RTLinux kernel.
For 'soft' realtime like my synthesizer, you need millisecond latencies. This is provided by BeOS, Ingo Molnar's Linux patches, and now the MonteVista patches. Not by Windows or WindowsNT.
For mp3 playing, you just need buffering, and you can have shit latencies. This can be implemented under any OS.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
Windows has had pre-emptable kernel and advanced thread scheduling since Windows NT 4.0, a time of several years. Good to see that the Linux guys are finally getting around to it.
It's interesting to see that they are going down the same path as MS - improving GUI performance by putting specific hooks into the kernel. Everyone knows that this is why Windows crashes.
Personally I'd like to see the Linux kernel stay as a kernel and not have any GUI, video or multimedia stuff "integrated". Hasn't it always been a strength of Linux that you only install what you need, and compile a kernel with only the bits you want? A lot of people don't use X-windows, and like Linux's fast performance under those conditions.
This company seems to be trying to create an open-source version of MS Windows. Is that what we want?
All device drivers have to be re-compiled though.
Similar software is available for NT. However it is difficult to recompile device drivers for it. If a device driver disables interrupts, then the real-time concept gets preempted.
I am desperately awaiting the 2.4 kernel. Three companies I work with are all waiting for the 2.4 kernel. Basically the number of processes and filehandles make the OS unscalable for our application (Lotus Domino). Currently out of the box it only will support about 150 concurrent users after tweaking.
Hmm... Lessee:
GIMP version 1.0.4
Well, it's not 1.0.0, but it is 1.0.x. Your point? I'm not ready to have 1.1.x eat my work just yet.
I rather like our even-odd version scheme, since it is actually comprehendable, and uses the digits to reasonable effect. Compare to much of the commercial software world, which only increments the leading digit, and includes the ".0" at the end just to make it sound official. (Or, once they get bored of that, they just start naming the software after the year that they thought it would ship in.) How can you tell an alpha from a beta in that scheme?
--Joe--
Program Intellivision!
Did any moderator notice the ";-)" at the end of my post? Hello?
--------
"I already have all the latest software."
I haven't tried 2.4, that should have said 2.0. I guess it's time to give it a try and see what I get . . .
I wish them luck - the more realtime capabilities are available in Linux, the more applications can use it instead of either specialized embedded system OS's or close-enough Windows products.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
It's still timesharing, you've just given root the ability to do a "notnice" as well as nicing things :-) More precisely, hard realtime schedulers let you guarantee response times to applications that need it, typically on the few-microseconds or few-milliseconds scale, and the "every process is equal" gets replaced with "some processes are better than others, but every process of the same social class is equal." Yes, this means the low-class tasks may starve; if you don't like that, don't schedule too many high-priority tasks.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks