Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

238 comments

Sorry! There are no comments related to the filter you selected.

Wow! (1, Interesting)

Free Bird (160885) | more than 12 years ago | (#2427737)

Cool! I really hope this'll make it into the official kernel, hopefully even 2.4 (though I doubt so not that 2.5 has been started).

Microsoft Anthrax attacks (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2427827)

Can't be cunted to go through all the indeterminable drivel down below. Just wanted to ask if the general Slashdot opinion towards the Microsoft Anthrax attack is along the lines of "hahahahaha! Serves them right for being Micro$oft!"?

Fucking Linux Cunts. Pathetic bastards.

Re:Microsoft Anthrax attacks (1, Funny)

Anonymous Coward | more than 12 years ago | (#2427891)

Is it a Worm, is it a Virus, does it use Outlook?

Re:Microsoft Anthrax attacks (1, Insightful)

Anonymous Coward | more than 12 years ago | (#2428008)

Is it a Worm, is it a Virus, does it use Outlook?

Its a Virus [mcafee.com] .

Re:Microsoft Anthrax attacks (1, Funny)

Anonymous Coward | more than 12 years ago | (#2428054)

After the MS anthrax attack, I saw Linux geeks dancing and celebrating in the streets on CNN. Fucking assholes. We should bomb them.

1991 (0)

Anonymous Coward | more than 12 years ago | (#2428101)

No, that was old footage.

US declares war on Finland (0)

Anonymous Coward | more than 12 years ago | (#2428103)

the US has begun nightly bombing runs and commando assaults on the pitiful country of Finland, and preliminary reports suggest that Tove Torvalds has been captured and pack-raped by Green Berets. more news as it cums.

So will that make Linux a superior audio platform? (3, Interesting)

geekplus (248023) | more than 12 years ago | (#2427740)

The reductions in latency -- would that include the type of latency that plagues real-time audio applications like sound-on-sound recording?

Re:So will that make Linux a superior audio platfo (1)

keesh (202812) | more than 12 years ago | (#2427750)

Nope. Decent sound-on-sound recording uses pretty large buffers to get around that sort of problem.

Re:So will that make Linux a superior audio platfo (1, Troll)

Starship Trooper (523907) | more than 12 years ago | (#2427789)

No, unfortunately. Professional audio processing requires an extremely special form of real-time processing that is pretty much only good for handling audio, and which actually can cause problems with any other types of software. Therefore, it is unlikely that preemption patches for Linux, which must remain a general-purpose system, will be made. Even most Windows professional audio programs don't use Windows' built-in scheduling; they instead take advantage of Windows' rather loose kernel hooks to preempt the operating system and handle real-time scheduling for themselves.

Look at BeOS for an example of why this sort of processing can't possibly fit into a normal-use system. BeOS was constructed especially for the handling of low-latency media such as audio, but as anyone who tried to program it can tell you, it was exceptionally difficult to program anything other than media apps with it! The extremely high-resolution threading of the operating system made even the simplest programming tasks near impossible, as mutex locks and thread conditionals needed to be spread throughout the code to ensure proper execution. This is why BeOS ultimately flopped: it was too hard to program for.

But, of course, this is an area where Linux could shine. Due to its open-source nature, a special media-processing fork of the kernel could be made for those who need to deal with real-time audio, while the general-purpose kernel remains general-purpose. In fact, DeMuDi Linux [xdv.org] is already striving for this goal.

Re:So will that make Linux a superior audio platfo (5, Informative)

Xoro (201854) | more than 12 years ago | (#2427864)

I don't want to sound like I'm contradicting you, but did you happen to read this link [gardena.net] from the article? It's specifically about realtime audio. Key paragraph:

*EXCITING* NEWS: things getting almost perfect ! Ingo's lowlatency-2.2.10-N6 patch with the shm.c part backed out and a modification of filemap.c (thanks to Roger Larsson) performs _REALLY_ well, using my usual latencytest parameters (4.3ms buffer), I got NO DROP-OUTS anymore, with sporadic maximum peaks of ONLY 2.9ms This is really exciting because it opens the doors to a whole new class of Realtime applications for Linux, simply using userspace processes scheduled SCHED_FIFO. I heard of comparable low-latencies only from BEOS, Windows can't simply guarantee these kind of latencies, not even using DirectX. Using a soft-synth on Win98 on my BOX I must use 15-20ms audio buffers to get _SOMEWHAT_ reliable audio. This is actually about more than 3-4times the buffer I used for testing under Linux ( 4.35ms).

I don't know much about the field, but the page seems to speak to several of the audio-related concerns mentioned above.

Re:So will that make Linux a superior audio platfo (0)

Anonymous Coward | more than 12 years ago | (#2428169)

Those low latency patches have been around for a while. Why haven't they made it into the kernel?

Re:So will that make Linux a superior audio platfo (1)

NeoOokami (528323) | more than 12 years ago | (#2427900)

I couldn't disagree more. BeOS is far from hard to program for. The API's are relatively simple, in fact BeOS is one of the only O/Ses you can read people calling a joy to code for. How much do you even know about it?

Re:So will that make Linux a superior audio platfo (3, Informative)

Lando (9348) | more than 12 years ago | (#2427984)

Ummm,
Sorry, just want to note that mutex and semaphore programming is not all that difficult if you do it much. True windows have a few kinks, but the concept is pretty basic. Basically I would have to disagree that mutex and thread programming makes programming hard. It's just programming once you understand it, it's pretty straight forward.

As for the windows problem use startthreadx instead of startthread (Yeah probably not the real api functions, but close enough haven't worked on windows for a while.)

Lando

Re:So will that make Linux a superior audio platfo (1)

bmacy (40101) | more than 12 years ago | (#2427986)

OK... I'm confused... this is extrmeley off-topic and I've never touched BeOS (besides failing to install it) so I don't know what I'm talking about.

Are you saying that in a multi-threaded program BeOS was so finely preemptible w/ small time slices that you couldn't be sloppy with resource contention like you can get away with on most UP platforms? I can't see any other way a scheduler would effect a user application.

Or maybe the application framework you used for BeOS applications allowed events to be handled in parallel? Or...?

Brian Macy

Public Service Announcement from Brokaw & Torv (5, Funny)

waldoj (8229) | more than 12 years ago | (#2427746)

We're sorry, but tonight's "Linux" will not be aired. Normally you would find 2.4.12 or 2.4.13-pre2 on Sunday nights, but not this evening. Now that Linux is fully preemptible, NBC will be airing a four-hour music-and-ice-skating tribute to Bill Gates.

We apologize for any inconvenience, and for the reduced uptime. Enjoy the show.

Finally.. (2, Interesting)

Renraku (518261) | more than 12 years ago | (#2427755)

You'd think this would have been one of the first few 'features' of the Linux core. If the latency were high, it would screw programs and things that rely on low latencies to compute. Better late than never.

Preempt Patches in Kernel (1, Informative)

terrabit (50647) | more than 12 years ago | (#2427757)

Does anyone think that this will ever make it into the kernel? It seems that Linus does not like this because it cures the symptons of latency in the kernel instead of the real problems.

Re:Preempt Patches in Kernel (0)

Anonymous Coward | more than 12 years ago | (#2427868)

...flaimbait?...love the smell of moderators on crack

Re:Preempt Patches in Kernel (1)

entrox (266621) | more than 12 years ago | (#2427882)

Why was this modded 'flamebait' ?

The poster raises a valid point which reflects Linus' attitude pretty good. IIRC Linus himself said, that they should rather fix the CAUSE of those latencies instead of the symptoms. This is one of the reasons, why Linux is against kernel debuggers. They tend to lure the coder into fixing symptons on the surface instead of perhaps rethinking the design (off by one errors are an example).

Re:Preempt Patches in Kernel (0)

Anonymous Coward | more than 12 years ago | (#2427893)

Seems like I am only allowed to moderate it as "underrated" once :(

Sorry

Re:Preempt Patches in Kernel (1)

Thatman311 (316281) | more than 12 years ago | (#2427932)

Uh? Why would he be against kernel debuggers? A kernel debugger is used to debug the kernel so how in other words do you debug a problem when you are developing new features that sit in the kernel or if you need to try to debug a problem that you see in the kernel? Do you have any sources on this statement cause I would love to read it.

Re:Preempt Patches in Kernel (1)

entrox (266621) | more than 12 years ago | (#2427976)

Here's what I found on the kernel cousins:

http://kt.zork.net/kernel-traffic/kt20001002_87. ht ml#4

Hmm (3, Interesting)

drinkypoo (153816) | more than 12 years ago | (#2427762)

I thought the Slack 2.0 release had a 1.1 kernel.

I'm wondering about this paragraph:

We had to modify the interrupt code in entry.S to prevent some situations and to allow preemption on return from an interrupt handler. However, we can't preempt within critical regions for the same reason we can't allow concurrency within them with SMP -- so we prevent preemption while holding a spinlock. The bottom half handler and scheduler were also modified to prevent preemption while they are executing.

Can anyone give a nice layman's description of what he's talking about here?

Re:Hmm (1, Informative)

Anonymous Coward | more than 12 years ago | (#2427783)

If the kernel is preventing the same piece of code from running on more than one processor (by acquiring a spinlock), then it is also preventing the code from being preempted.

Re:Hmm (5, Informative)

selectspec (74651) | more than 12 years ago | (#2427823)

The interrupt handlers can't allow premption during the context switch of an interrupt because the registers are intransit. Basically, you can't have an interrupt while your in the process of any kind of context switch otherwise you're never sure what registers you were able to flush to and from the CPU to the stack.

Critical Sections (such as access to the IP stack or I/O queues) have to be protected. With the advent of multi-processor systems under the SMP scheme, there is already considerable locking within the kernel to synchronize access of critical resources between processors. Critical regions also need to be protected from interrupt concurrent access as well.

Bottom Half handlers generaly are fast track implementations to quickly deal with the interrupts. To avoid concurrency collisions of reasources used within the bottom half handlers, interrupts (for that particular handler) must be disabled during the handler's execution.

All in all, this is basic non-preemptive stuff. What I don't understand is that this strategy that he is defining is a textbook NON-premtive approach to kernel design. I'm not too sure where he gets off claiming that the kernel is fully-preemptive here.

Re:Hmm (5, Funny)

Anonymous Coward | more than 12 years ago | (#2427880)

Only on slashdot would "IP stack", "I/O queues", "interrupt concurrent access" and "SMP" be considered laymans terms.

Re:Hmm (5, Informative)

sagei (131421) | more than 12 years ago | (#2428019)

I originally felt I should stay out of any discussion here, but I want to answer some of these questions and clear some of this stuff up. To be honest, it is a little embarrassing having everyone read and comment on the interview. :)

Bottom Half handlers generaly are fast track implementations to quickly deal with the interrupts. To avoid concurrency collisions of reasources used within the bottom half handlers, interrupts (for that particular handler) must be disabled during the handler's execution.

Interrupts, even just the in question, are not disabled during a bottom half, at least in general. The reason we can't preempt bottom halves is that they are guaranteed to be serialized w.r.t CPUs (ie a given BH runs on only one CPU at a time). Because of this, the BHs are designed without a regard reentrancy. So we can't preempt them.

All in all, this is basic non-preemptive stuff. What I don't understand is that this strategy that he is defining is a textbook NON-premtive approach to kernel design. I'm not too sure where he gets off claiming that the kernel is fully-preemptive here.

Hardly. Would you say an SMP system is not SMP if it is non-concurrent inside critical sections? No, you wouldn't, and this is the same situation we have here with preemption. We can't preempt inside critical regions. We have concurrency and reentrancy concerns, just like SMP does. We also can't preempt inside interrupt handlers or bh's because they aren't designed to be preempted (nor would you want to interrupt the top half of an interrupt, anyhow).

The current kernel is not preemptive _anywhere_. The only way, in fact, kernel code ever yields execution is if it explicitly does so or returns. Since with the preempt-kernel patch we can now preempt in 90% of the kernel, I think its safe to say we have a preemptible kernel now.

Links on Spinlocks, etc (5, Informative)

Alien54 (180860) | more than 12 years ago | (#2427844)

There are these links:All around useful stuff, enough to get you started destro^H^H^H^H^H^H hacking your own kernel

Linux Devices Article (4, Informative)

Alien54 (180860) | more than 12 years ago | (#2428121)

The Linux devices article link should be:

http://www.linuxdevices.com/articles/AT4185744181. html [linuxdevices.com]

Goofed that up.

Nice discussion, from Sept 6, with related links

[sigh]

Re:Hmm (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2427878)

Woohoot.

Well I just bet your speakers have already got preemptive multiprocessing....
wank into those subwoofers boy.

MWHUHAHAHAHAHAHAHAHAHAHA

Re:Hmm...laymans terms (2)

A_Non_Moose (413034) | more than 12 years ago | (#2427888)

The left hand (processor 0) needs to know what the right hand (processor 1) is doing.

Reverse if necessary.

Ambidexterous people...just HUSH! :)

Heh, how about that, computers do have a real life (tm) frame of referrence.
Moose.

Re:Hmm (4, Informative)

sagei (131421) | more than 12 years ago | (#2428038)

I thought the Slack 2.0 release had a 1.1 kernel.

It could of, I just seem to remember a 1.0 kernel.

Can anyone give a nice layman's description of what he is talking about here?

Basically I am explaining the modifications to the kernel we made in order to make it preemptible. To try to put it more for the layman, besides just allowing the kernel to preempt itself as needed, we had to prevent some certain situations from being preempted. This is the same situation with SMP. We use SMP's locks to disallow preemption, for concerns of concurrency and reentrancy. We can't preempt during interrupt or BH handling because those things are not designed for concurrency, either.

To sum it up, we have to prevent preemption in some situations. Those situations are: while locks are held, while handling interrupts and bottom halves, and while inside the scheduler itself.

Re:Hmm (0)

Anonymous Coward | more than 12 years ago | (#2428078)

"It could of, I just seem to remember a 1.0 kernel."

could HAVE, not could of.
you are probably thinking of could've, which is a short form of could have.

Best line from the interview: (4, Funny)

mike_the_kid (58164) | more than 12 years ago | (#2427772)

JA: What tips and inspiration can you offer aspiring kernel hackers?

Robert Love: Read the source, play with the source, and bathe regularly.

All computer science labs should have available eye-wash style emergency showers.

Re:Best line from the interview: (0)

Anonymous Coward | more than 12 years ago | (#2427796)

Actually, I'd love to be able to hack on the kernel while in the bath/shower/pool or lolling in the gentle surf of a tropical beach. There are few places I'm more comfortable than in the water

Although, apparently, no matter what the temperature, after a while (max. tolerance is about 24-48 hrs immersion at body temperature) the human temperature regulation system is shot to hell and you go hypothermic/cold-blooded i.e. unable to regulate your own body temperature. Doesn't matter so long as the temperature is set to just below body temp. I guess, but dangerous none the less. Osmotic pressure could f*ck you up too...

Re:Best line from the interview: (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#2428153)

There are few places I'm more comfortable than in your mom.

Re:Best line from the interview: (0)

Anonymous Coward | more than 12 years ago | (#2427876)

especially for dealing with linux source, damn that stuff gets ugly in places.

gay (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2427777)

why do a lot of homosexuals talk with a lisp?

Re:gay (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2427800)

why do a lot of extraordinarily stupid individuals feel the need to broadcast their stupidity to the rest of the world?

Re:gay (0)

Anonymous Coward | more than 12 years ago | (#2427805)

why do a lot of extraordinarily stupid individuals feel the need to broadcast their stupidity to the rest of the world?

Don't be so hard on yourself.

Re:gay (0)

Anonymous Coward | more than 12 years ago | (#2427832)

why do a lot of extraordinarily stupid individuals feel the need to broadcast their stupidity to the rest of the world?

So idiots like you will reply. Jackass. Go eat poop.

Re:gay (0)

Anonymous Coward | more than 12 years ago | (#2427839)

Go eat poop

Eating poop is a very bad idea, as it is highly toxic and can cause severe sickness, or even death.

Re:gay (1)

wholesomegrits (155981) | more than 12 years ago | (#2427973)

That's the idea...

Re:gay (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2427819)

I don't know, probably the same reason you have your lisp?

ummm (-1)

j0nkatz (315168) | more than 12 years ago | (#2427782)

We preempt this Linux kernal to bring you a very important OS! WINDOWS FUCKING XP BABY!

Ok, I'm missing something (2)

Quasar1999 (520073) | more than 12 years ago | (#2427788)

Can someone fill me in... Hasn't Microsoft been claiming windows has been preemptive since win95??? Is this some other form of 'preemptiveness'?

What is this 'preemptive' thing refering to? Task scheduling?

Re:Ok, I'm missing something (0)

Anonymous Coward | more than 12 years ago | (#2427803)

When a thread is running in user space it is preemptable.
Once it enters the kernel, it executes without interuption until it returns to usermode.

Re:Ok, I'm missing something (1)

Quasar1999 (520073) | more than 12 years ago | (#2427879)

I see, but was Microsoft's OS preemptible when executing inside its kernel?

I'm trying to determine if Windows has/had a better kernel design than linux.

Re:Ok, I'm missing something (0)

Anonymous Coward | more than 12 years ago | (#2428015)

NT is. 9x isn't.

Re:Ok, I'm missing something (4, Informative)

jeffy124 (453342) | more than 12 years ago | (#2427892)

pre-emptive is a form of multi-threading. the other form is co-operative.

Co-operative means that threads relinquish control on their own. This meant that a greedy thread could put a serious stranglehold on the OS and lock-up the system, forcing a reboot.

Co-operative was used in every Mac prior to and including OS-9, which made it very unstable should a thread crash.

Pre-empt means the OS decides when the thread loses control. A thread can still voluntarily relinquish control, but the final call still comes down to the OS.

OS-X is fully pre-empt, meaning a crashed thread doesnt crash the entire system, bettering the stability overall as that will usually only crash the program that thread belonged to, not the entire system.

I dont know what MS has for their threading model, they seem to have a very bad hybrid system. The threading in Windows 95/98 tends to cause a good number of BSODs. NT/2000 OTOH, had a better model and crash a lot less often, which is why they have traditionally been the more stable MS OS.

Task scheduling has to do with what thread gets control next. Priority and other factors decide that. Solaris threads have 2^31 possible levels of priority, Windows (all versions, IIRC) has 5 classes and then 5 sub-classes of priority for each (a REALLY screwed up and tough to understand and explain technique, iow not a clear-cut 25 levels), and Java has 10 levels for cross-platform threading. Each model has their plusses and minuses, but that's getting offtopic from preemptive vs. co-operative.

Re:Ok, I'm missing something (3, Informative)

Yokaze (70883) | more than 12 years ago | (#2428096)

Not quite correct.
It's not preemptive vs. cooperative.

But preemptible vs. non-preemptible kernel.

"Pre-empt means the OS decides when the thread loses control."
Yes, that's preemption.

B,ut there is another preemption.
Should a process get a higher priority than the currently running process, then the current process gets preempted.

E.g.
You have a low priority CPU-bound process A(e.g. Seti@home) and you have a high priority I/O-bound process B (e.g. XMMS).
Usually, B does nothing but waiting for I/O (e.g. the soundcard and the harddisk). While waiting, the process is not in the run-queue.
Meanwhile, A hogs the CPU. Usually, when the I/O request is done, the CPU gets an interrupt request (IRQ) which causes the OS to switch in kernel mode and handle the request. B gets active again and has a higher priority than A, so A gets preempted. Usually that works fine, but now A wants to do some I/O (deliver a packet) and calls the kernel, which handles the request. Just this moment is the I/O for B ready. In Linux (as in most other OSs too) B has to wait until A gets its syscall done, since the kernel is not preemptible. This period of time until the B gets the CPU increases the latency.

Windows 95 is preemptive (at least according to A. Silberschatz) as is Linux.

The high amount of crashes of the whole system stem from the resource protection (direct hardware access), not the scheduling.

Re:Ok, I'm missing something (2, Informative)

Anonymous Coward | more than 12 years ago | (#2428123)

As I understand it:
NT has 32 priority levels.

The split into idle (p=0), low, below-normal, normal, above-normal, high and realtime (p>=16) (which I assume is what you were referring to) is just a simple way to name different general priority levels. It's the 32 levels that matter.

Normal priority is 14.

Anything running at 16 or above ('realtime') will never get interupted by threads running at lower priorities. The OS will never change these priorities, though the user can.

Ready to run threads of priority =14 can be given a temporary priority boost to 15 (lasts for a double timeslice which is 40ms normally) if they have been ready to run for about three seconds. Anything at lower than priority 16 shares what time is available, with higher priorities being favored. At priorities lower than 16, no thread will ever be totally starved of CPU time.

Priority 0 is for things which should only run when nothing else needs CPU time, like RC5 or SETI@home (though some such apps actually set themselves to priority 4 and hence slow most things down. folding@home used to do this).

Re:Ok, I'm missing something (4, Informative)

sagei (131421) | more than 12 years ago | (#2428064)

Can someone fill me in... Hasn't Microsoft been claiming windows has been preemptive since win95??? Is this some other form of 'preemptiveness'?

You are thinking of forms of multitasking. One form is preemptive, in which tasks are given a specific period in which to run (timeslice) and then forcibly preempted by the next runnable task when that quanta ends. Win95, NT, all Unices, and anything decent fit in here

The other form is cooperative, in which tasks run until they yield execution. This is how Win 3.1 is. In 3.1, tasks ran until they finished processing their current Windows Message or called yield().

This article is about a preemptive kernel, where actually the same ideas apply. Inside the kernel, things are currently cooperative in the sense the kernel code runs until it completes or yields control. This patch makes it preemptive -- it will be preempted when something more important needs to happen.

Win95 does not have a preemptive kernel (it isn't even reentrant). NT might. Solaris does. Linux does with this patch.

Re:Ok, I'm missing something (3, Informative)

joe user jr (230757) | more than 12 years ago | (#2428066)


windows has been preemptive since win95??? Is this some other form of 'preemptiveness'?

Windows' "preemptiveness" refers, as explained somewhere else here, to the windows kernel being able to jump in and stop any user process executing to give the next one its term - so (in theory) no user-run program can hog all of the CPU and resources.


Linux has always done this - it's the standard way to write a unix kernel.


In relation to the audio discussion, preemptive in a linux kernel means (as far as I understand it) that the kernel attempts to guarantee a minimum time between an interrupt coming in on some device and control being handed to the driver for that device. It does this by preempting its own tasks in order to hand control over to the driver for the device needing the attention (the driver, of course, runs as a kernel process, also).


Typically, the goal is to get a maximum latency of 10ms or better (less) between the interrupt and the waking up of the driver.


In a professional audio situation, of course, the user can go a long way by stripping all the unnecessary hardware and tasks out of the configuration of the machine, which will mean that (if done properly) the only thing which can get in the way is linux' internal book-keeping. This is a different situation to playing with audio apps on a networked computer while you print out web pages.. ;)


Beyond this, there is real-time linux in which (as I recall) a hard maximum latency of 2ms or so is claimed. But the overheads introduced by all the timing and checking which guarantees this impact the performance to the extent that it's quite a different beast, for specialised applications.


Some audio programmers would like a low-latency patch (either the preemptive one or some other) which has a soft guarantee of "almost all" latencies below 5-10 ms to go into the standard kernel because they would like their userbase not to have to deal with the complexities of kernel recompilation and/or patching, but this is a pretty tall order because Linux will not like having basically ugly fiddly designs with lots of volatile little conditionals which have to be fiddled with everytime something changes going into the beautiful kernel.


Maybe vendors like mandrake should pick up the baton and provide a low-latency alternative kernel installable with their gui tools or at install time, which would keep everyone happy at the cost of not too much effort and space.

I'm not sure... (2, Interesting)

TheMMaster (527904) | more than 12 years ago | (#2427794)

I think this is a good short-term solution for the latency problems but I personally wouldn't include it in the main kernel releases. I believe that it *might* be a good idea to fork the kernel releases (temorarily) in two groups: One for servers and one for workstations until the problems have been solved.
I think that (for now) using this patch on workstations is a pretty good idea. And I think that there should be a better solution for the problem witch should THEN be something along the lines of kernel 3.0
I am not a kernel developer or anything, but I am currently reading up on the source and the mailing lists.
Basically all I am trying to say is: Make it work NOW and solve the real problem later. Just make sure that is WILL be solved... (no microsoft coding ways here ;-)). We still need a larger user base...

Re:I'm not sure... (3, Informative)

STSeer (119553) | more than 12 years ago | (#2427873)

Love said that this patch even if added to the main tree would still be a config option.

Re:I'm not sure... (3, Interesting)

debrain (29228) | more than 12 years ago | (#2428057)

Actually, given the current state of the vm parameters set almost exclusively for a workstation (since bdflush chokes a server real good), would seem to dictate that you have to tinker with the kernel anyway and that forking the kernel itself wouldn't necessarily help since the number of forks for each configuration of properly scalable high intensity server would be enormous. It works good for a workstation, and perhaps preemption should be default on a workstation (I use Love's patch on mine), but splitting the kernel between workstations and servers is probably not the best way to go about making servers customized to their personal best performance level since the configuration is quite sticky anyway.

Re:I'm not sure... (5, Informative)

sagei (131421) | more than 12 years ago | (#2428171)

Disclaimer: It's my patch

I think this is a good short-term solution for the latency problems but I personally wouldn't include it in the main kernel releases. I believe that it *might* be a good idea to fork the kernel releases (temorarily) in two groups: One for servers and one for workstations until the problems have been solved.

I tend to look at this more of a long-term solution, and I think people who see it has a short-term solution or hack are missing the point. First, this is a feature. We aren't kludging kernel code so that we can lower latency by stopping it when needed. We are effectively using the SMP code to multitask better within the kernel.

Second, forking the kernel over this is a terrible idea. Since it is a config setting, this is a non-issue anyhow, but I really don't want to see this thing forked off. In fact, I think the ideal situation is where we can get a preemptible kernel that benefits throughput so that server processes benefit from it as well.

I think that (for now) using this patch on workstations is a pretty good idea

Agreed :)

And I think there should be a better solution for the problem witch should THEN be something along the lines of kernel 3.0

There isn't a better solution that is not a hack. There is a reason Solaris, NT, and all RTOS are preemptible inside the kernel: it is the only way to achieve real-time response. You just _have_ to be able to respond to events when needed.

The "better" solutions in this case are "simpler" -- if we can hack some conditional schedules into places, perhaps simplify some algorithms, etc. then we can perhaps reduce latency without preemption. This is what Andrew Morton's low-latency patches do. But we need more. The point is not that preempt-kernel is a hack, but that it is a whole new high-tech feature, and some people want to find a simpler solution.

Personally, I don't think a simpler solution exists, and I believe the preemptive kernel satisfies other problems (and it also a neat feature:>). Thus I work on it.

needed badly (4, Insightful)

xah (448501) | more than 12 years ago | (#2427804)

A fully preemptible kernel is important to the future of Linux. Everyone knows that the system will lock up a lot if it's misconfigured, or if a piece of hardware is buggy.

So long as the console driver and the keyboard driver are alive, root should always be able to open a new shell and kill an offending process that is hanging the rest of the system. Right now, this is too frequently a non-option.

Re:needed badly (1, Insightful)

Anonymous Coward | more than 12 years ago | (#2427969)

Confusion again about the terms.. The only way bad software takes down the system right now is if it runs the machine out of an available resource (such as ram)

Pre emptive kernel will NOT help this case.

Re:needed badly (1)

xah (448501) | more than 12 years ago | (#2428047)

I'm pretty sure that a buggy driver can take down the system. Wouldn't a pre-emptive kernel stop that?

Re:needed badly (0)

Anonymous Coward | more than 12 years ago | (#2428063)

Won't help at all .. buggy drivers will still take down the system.

On the upside since pre-emption acts a lot like SMP. SMP users should find the drivers they want better debugged.

Re:needed badly (1, Informative)

Anonymous Coward | more than 12 years ago | (#2428001)

Wrong, dewd. You're thinking of a microkernel. They're two totally different architectures.

What does that mean? (2, Interesting)

BlackGriffen (521856) | more than 12 years ago | (#2427809)

I thought giving the Kernel the ability to preemt other programs was important. If you give programs the ability to preempt the kernel, doesn't that just change the system back to cooperative multi-tasking? I could just see programmers abusing the ability to preempt the kernel to squeeze a little more speed out of their app.

Re:What does that mean? (0)

Anonymous Coward | more than 12 years ago | (#2427824)

You're giving the scheduler the ability to preempt threads executing in the kernel.

You're not giving applications to ability to preempt other threads at will, or to make themselves unpreemptable.

This isn't abusable (excluding exploitable bugs).

Re:What does that mean? (2, Informative)

naasking (94116) | more than 12 years ago | (#2427863)

No, I think you're misunderstanding. It's not preempting the kernel, it's preemtping a lower-priority thread that happens to be in the kernel (ie. during a system call). If there is a runnable thread with a higher priority, it should be set running. But as things currently stand, if the low-priority thread is in the kernel it can't be preempted, and so the high priority thread has to wait. That is bad.

Re:What does that mean? (2)

Adnans (2862) | more than 12 years ago | (#2427867)

I thought giving the Kernel the ability to preemt other programs was important. If you give programs the ability to preempt the kernel, doesn't that just change the system back to cooperative multi-tasking?

Nope, because the kernel is still always in control. In a cooperative multi-tasking enviroment the userspace programs can choose to hold on to the processor as long as they like (i.e. not cooperate nicely with others). This patch simply allows a lower priority process to be interrupted by a higher priority one even if the low priority one is in the kernel, doing a system call for example. However, this preemption is done by the kernel scheduler.

-adnans

One character. Hmm. Gee, might this be a troll? (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2427817)

x

Re:One character. Hmm. Gee, might this be a troll? (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2427848)

y

LOOK, NO CHARACTERS! (by keesh) (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2427895)

Re:LOOK, NO CHARACTERS! (by keesh) (0)

Anonymous Coward | more than 12 years ago | (#2428053)

conjecture:
all posts are trolls.

proof method:
show that a post with n characters is considered a troll.
show that a post with n+1 characters is considered a troll.

proof:
let n=0
for a post where n=0 (i.e. with zero characters) click link (* [slashdot.org] )
Note the moderation.
for a post with n+1 characters click link (* [slashdot.org] )
Again, observe the moderation.

Therefore, it is proven by mathematical induction that all posts are considered trolls.

Re:LOOK, NO CHARACTERS! (by keesh) (0)

Anonymous Coward | more than 12 years ago | (#2428072)

Proof by induction is not proof. And you just copied that from fortune, anyway.

www.goatse.cx (-1)

Proctal Relapse (467579) | more than 12 years ago | (#2428093)

www.goatse.cx [yahoo.com]

Background and a different patch (5, Informative)

alewando (854) | more than 12 years ago | (#2427831)

If you're wondering what the heck a preemptive kernel entails, then here's some background [gatech.edu] .

Also, if you don't like Robert Love's implementation, then Andrew Morton maintains a patch [uow.edu.au] with a similar low-latency goal.

A better URL (1)

foo (143650) | more than 12 years ago | (#2428172)

http://www.uow.edu.au/~andrewm/linux/schedlat.html

What does it mean to me? (0)

CTho9305 (264265) | more than 12 years ago | (#2427838)

As a gamer/user, in what way does this benefit me? I don't really understand what the "latencies" are, and where it would improve my framerate ;-)


if anyone would care to explain / provide links that would be great

OS-X (1)

jeffy124 (453342) | more than 12 years ago | (#2427846)

Mac OS-X is fully pre-empt already, making it a greatly stable system.

I can only see a fully pre-empted Linux increasing it's already solid stability.

Now if only we could remove co-operative threading from windows....

Re:OS-X (2, Informative)

JanneM (7445) | more than 12 years ago | (#2427943)

Linux is fully preemptible, and has always been. This is about being preemptible while executing in the kernel. I have no idea if OSX allows this or not - it's BSD based, so probably no, but then Mach is involved someway or other, so maybe. It would be interesting to know.

/Janne

Re:OS-X (1)

jeffy124 (453342) | more than 12 years ago | (#2427965)

the marketing blitz about OS-X has indicated "fully preemptive multitasking" See http://www.apple.com/macosx/ [apple.com]

Re:OS-X (1)

JanneM (7445) | more than 12 years ago | (#2427978)

Yes, yes, but does Darwin preempt _running in the kernel_? It's not the same thing.

"Fully preemptive multitasking" is about preempting userland programs - and Linux (and other Unices) has had this since day one.

/Janne

Re:OS-X (1)

jeffy124 (453342) | more than 12 years ago | (#2428000)

that i do not know.

I suspect that the answer would be yes it does because Apple had to seriously overhaul the multitasking for the user layer, and knowing the amount of work they did for OS-X, I wouldnt see them not leaving out preemtiveness from the kernel. They also used the word "fully." If the left it out of the kernel, they couldnt use it.

But that's just my educated suspicion, i dont know for sure what fact is.

Re:OS-X (1)

sracer9 (126645) | more than 12 years ago | (#2428034)

They also used the word "fully." If the left it out of the kernel, they couldnt use it.

Remember, they also touted OSX as "The most advanced operating system in the world." Not that it's not a fine OS, but that's a bit of a stretch. Apple is well noted for it's marketing speak and as such, saying it's fully preemptible does not mean that the the kernel itself is preemptive. It very well may be, I just take what they say/advertise with a grain of salt. I've never been too keen on marketing speak.

Re:OS-X (0)

Anonymous Coward | more than 12 years ago | (#2427954)

This is preemptive KERNEL not task multitasking..

Bad processes do not often take out linux. (unless the admin forgot to set resource limmits

alright! (0)

Anonymous Coward | more than 12 years ago | (#2427857)

...and if it works, the linux folks will have finally caught up with circa-last-year FreeBSD SMPng efforts!!

preemptable linux eh..... (0)

Anonymous Coward | more than 12 years ago | (#2427874)

looks like www.OnCoreSystems.com has had that for quite a while now....and they have context switch times under 5 microseconds...ofcourse they are using linux as a application on their microkernel...

ATT@Home blocks port 25 (0)

Anonymous Coward | more than 12 years ago | (#2427898)

Hrm.. I know this is extremely off-topic, but I figure someone on Slashdot is having the same problems, so I'll ask. Are any of you using ATT@Home to host a mail server? Has your port 25 been blocked? Mine has. I hope something terrible doesn't have to happen to the local ATT@Home office...

Re:ATT@Home blocks port 25 (0)

Anonymous Coward | more than 12 years ago | (#2427914)

maybe they fear anthrax being sent via email

Need help from trolls (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2427899)

are there any good irc channels out there for trolls? I know there used to be #trolls on irc.slashdot.org but now it's gone. Help me out.

thanks!

-A troll

Don't confuse this with cooperative-vs-preemptive (1, Informative)

Anonymous Coward | more than 12 years ago | (#2428031)

This has nothing to do with cooperative vs. preemptive multitasking. In that sense, Linux (and every other Unix-like OS on the planet) has been preemptive forever.

This is about making the kernel preemptible, which means that a process can be preempted if it's in kernel space (i.e. making a system call) as well as when it's executing normal user code.

Without a preemptible kernel, a process can remain on the cpu during the several milliseconds that a system call can potentially take to return or sleep, even if a higher priority process becomes runnable during that time.

Windows 2000/NT (0, Troll)

Beatlebum (213957) | more than 12 years ago | (#2428080)

Of course it would be crass to mention that Windows NT/2000 has had a preemptive kernel from day 1. Facts and *nix polictical correctness don't mix too well at /.

Re:Windows 2000/NT (4, Interesting)

RelliK (4466) | more than 12 years ago | (#2428149)

Really? That's the first time I hear about that.

There is a difference between pre-emptive multitasking and pre-emptible kernel.
Pre-emptive multitasking means that the kernel can interrupt any thread and give control to another thread, so that a thread cannot hog the CPU resources. This is what all modern operating systems do, except Windows 3.1/9x/Me and MacOS (pre- X), though it could be argued that Windows 3.1/9x/Me is not an operating system much less a modern one ;-)

Pre-emptible kernel is a different beast. It means that the kernel can interrupt itself (i.e. a thread running in the kernel mode) and give control to another thread running in the kernel mode. This is used in real-time operating systems where you need to have a guaranteed maximum response time (i.e. a thread must not wait longer than a certain amount of time before it gets control). However, this is not all that useful for general-purpose OSes and may even be detrimental to servers, where throughput matter more than response time. So it's good to know that this will be a compile-time option.

And I wonder how many slashdolts know what (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#2428087)

a fully preemptible kernel is?

You guys should stick to the basics. Like the latest games coming out for the Playstation.

Windows 95 (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2428088)

Windows had a fully preemptive kernel in 1995. I know a am going to get moderated down, so I will say in advance BITE MY MICRO PENIS CMDR TACO

Re:Windows 95 (0)

Anonymous Coward | more than 12 years ago | (#2428120)

Windows 95 was released in 1996, don't you remember?

yes, but why? (3, Informative)

markhahn (122033) | more than 12 years ago | (#2428104)

it's all very well to say that you want to trade 5% of normal performance for a 200% improvement in latency. but why does anyone need better latency? afaikt, the latency here is strictly for people who want to do RT audio effects. this has nothing to do with audio playback, which has no latency sensitivity (because of buffering). this also has nothing to do with "feel", since humans are terribly slow, and cannot possibly feel the difference between 5 and 10ms.

I hope that Linus will look at whether these patches hurt the normal case. "normal" means things like kernel compilation, not just an arbitrary latency measure and dbench (one of the least realistic benchmarks possible!)

there are good reasons to be skeptical of all-out premptiveness: it will unavoidably lower throughput in easy-to-define cases. any intro OS text will talk about optimal scheduling, where 'optimal' requires a definition of throughput or some other metric. preemptive kernels will context switch more, and will probably interfere with the natural 'batching' that happens when a big job runs for a while. think about caches: you never want to switch unless you must. this is not an argument against low-latency! it's an arguement against lowest latency as an absolute; we need to set a target (5ms would be fine imo) and meet it. going beyond such a goal will hurt the normal case.

Re:yes, but why? (4, Insightful)

Spy Hunter (317220) | more than 12 years ago | (#2428161)

this has nothing to do with audio playback, which has no latency sensitivity (because of buffering)

Unless you're writing a game, where sounds have to happen at specific times synchronized with events on-screen. Or you're in KDE and you want a "minimize" sound effect to happen when you press the button, not a second afterward. Or you're writing a media player and you want to have an EQ that responds immediately rather than a second from now, making it a tedious chore to adjust the settings.

Large latency is very noticable in these situations. While it may sound like pointless whining to complain about the "minimize" sound effect being a second late, it really creates a bad perception in the user's mind about the speed of KDE. These things are actually important.

Options... (2, Informative)

Mike McTernan (260224) | more than 12 years ago | (#2428114)

Whether this patch is added or not is surely just a question of whether it is stable enough or not.

As it says in the interview, the enablement of the patch is an option in the config... For those that want it (i.e. most desktop users I would expect) it's there. For those that don't, it can be disabled.

It seems that the patch works, as scientifically explored by his benchmarks. If there is a fault in the patch, I'm sure that half of slashdot will email the chap.

In summary, it works, is probably stable and can be enabled/disabled in config if needed. It already does, and probably can, benefit lots of people.

Put it in!
(At worst it can be removed and a new kernel released the day after... hehe)

Hmm? (0)

Anonymous Coward | more than 12 years ago | (#2428150)

Isn't this pretty much what RTLinux does already?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>