[Linux4christians] Have You Built a Custom Kernel and Why?

[Marco Tedaldi]

On 24.01.2012 01:31, Eddy Martin wrote:
> On 01/23/2012 09:52 AM, Don Parris wrote:
>> I am curious to know if any of you have actually built a custom
>> kernel, and what advantages (if any) this gave you over (a) the
>> default kernel and (b) a comparable Windows system.  I ask about
[...]

> I built a custom kernel on Debian Stable a few months ago, and it was to
> take advantage of Realtime capabilities, as Stable doesn't have a
> Realtime Pre-emption enabled kernel pre-built and available in the repos
> like Ubuntu.
> I've heard for some time that the latest kernels available from
> kernel.org have Ingo Molnar's realtime patch built-in, but it is a
> "soft" realtime, compared to a "hard" realtime.

Pay attention on "realtime". There are a few different things that are
called "realtime" but are not.

For example, in windows you can set the priority of a process to
"realtime": This is a blatant lie!

Let's first define, what realtime is (and what is widely agreed upon
being "realtime" in the relevant industry)
Realtime just means "deterministic behavior" (would "determiniscability"
be a word?).
It dies NET mean:"fast" or something like that in any way.
"hard realtime" does mean, that the system will do what it is supposed
to do within a predetermined window of time. Guaranteed.
"soft realtime" means, that it is doing it almost always but it might
fail to do so from time to time. But at least it will let you (or the
application) know.

> Some would argue that you don't need hard realtime unless you are
> controlling robots to built rocket parts, but it does make a difference
> with audio/video work.

There are a lot of needs for "realtime" stuff. Every machine controller
must be realtime capable. For most imaging systems you need realtime
stuff (because buffers in the imaging device are not infinitely big and
you might loose data otherwise).

> As you might well imagine, I could NEVER do such a thing with Windows,
> so it's an automatic advantage.

There are versions of windows CE (someone remembers?) that are said to
be realtime... I know about this because in several situations the
door-controllers and lift controllers had to be rebooted several times a
day...

> In order to bring latency down to usable levels, they have such things
> as ASIO drivers and various optimization "tweaks" which I have no
> experience with, but the fact that Mac OS has historically been the
> preferred system for A/V is a bit telling.
>
On classic macs you could do realtime stuff... because it was no real
multitasking system. So a task could hog the cpu as long as it wanted
and the system did not interrupt it.
Like dos. You can easily do realtime stuff in dos (in fact, many
realtime systems still run on dos basis. For example some of the NI
systems for LabView RT run on a heavily modified dos system).


> The kernel itself performed like it was supposed to, but it wasn't the
> success I hoped it would be.

I don't know about the patches you have used. With an improved scheduler
you might get soft realtime. But hard realtime requires a lot more.
Hard realtime means, that your code is running on kernel level. With no
memory management (because memory management can make for
undeterministic delays). This means, if your code crashes, your system
goes down. The realtime part runs like a kernel-driver. Realtime and
all. And than you have normally a non realtime part (like communications
and user interface) running in user space. These two parts of an
application can communicate with each other over fifos, buffers and
shared memory space.

Writing such an application takes (especially the realtime part) takes a
lot of work and requres a lot of knowlege. Because just one access to
the wrong location done in the wrong way can make the whole thung
undeterministic.

> However, I think it was more due to me being a novice at it, and I
> couldn't run the display drivers accelerated to take graphics duties off
> of the CPU.

Yeah... when the cpu goes to 100% you can forget about realtime.
Realtime kernels can't "invent" processor cycles. And when there are bus
master transfers taking place (which is done when putting data to the
craphics card) even a realtime kernel can't interrupt this to do his stuff.

> I imagine I'd have to sit on IRC with a bunch of kernel hackers to
> really "get" it, but I can't say it wasn't worth the experience.
> 
Or with a realtime expert...
To get a realtime sstem to perform as it should you have to look at all
the possible bottlenecks. And there are a lot of them around. Todays PC
with a modern multi tasking operating system tend to do a lot of stuff
in non deterministic ways. Thus getting a system to do realtime is most
probably a lot more than some kernel patches... sadly.

> Probably the best reasons to compile a custom kernel would be for much
> the same reasons; incorporating a patch, enabling things that are not
> turned on by default, custom drivers, etc.
> They all are valid reasons, but probably only a very few situations that
> would really call for it.

I can only agree on that.

> I'd say get comfy with the process just because the cert requires it,
> and who knows?

It is for sure not wasted effort to learn it. Can also help you
understand the structure of the kernel a bit.

> Maybe somewhere down the line, you'll really need to know how to do it,
> and you'll be ready.est

+1

best regards

Marco