Re: Kernel built with CONFIG_PREEMPT_RT

[Lars Segerlund <lars.segerlund@gmail.com>]

 Hi , it's not my intention only to reply to sender, a mix of mailprogram & incompetence ... about 50/50 ....

 Anyhow, sorry, and here are the links for all ....

 Still, I really hope this is a good idea and we get some low-latency kernels built, and when RT goes in mainline, it's an easy transition :-D ...

 / Lars Segerlund.

2011/7/12 Luis Henriques <luis.henrix@gmail.com>

Hi,

(why do you keep replying only to the sender?)

Lars Segerlund <lars.segerlund@gmail.com> writes:

> Here is a link to the FAQ on the matter on the RT wiki :
>
>  https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions#
> What_are_real-time_capabilities_of_the_stock_2.6_linux_kernel.3F
>
>  Also if you check : https://www.osadl.org/
> Realtime-Linux.projects-realtime-linux.0.html
>
>  The time is coming closer when RT is in mainline :-D

Well, we keep hearing this for ages now... :-)

I guess there's still a long way to go, and as Linus doesn't seem very
excited about it, so it can take a while.

>  I think CONFIG_PREEMPT_VOLUNTARy is a good choise for the default, since
> CONFIG_PREEMPT might give a performance penalty for some loads, I think a
> separate kernel packet for low-latency or something would be a good choise.

I see your point, but I'm still not convinced that for a desktop system
(the -generic flavour in Debian) CONFIG_PREEMPT_VOLUNTARY is the best
choice (but I don't have any numbers to prove otherwise).  I've been
using the CONFIG_PREEMPT on my laptop for ages, and actually used
PREEMPT_RT for a while as well.

(btw, another interesting possibility for the desktop would be the
BFS... but let's not start this discussion :-) ).

>  High resolution timers are also needed but I think they are configed as
> default.

Yes, it is.

>  It would be so nice for 2.6.39 or 3.0 ... to stop having to rebuild all the
> time ...

What's wrong with rebuilding the kernel?

$ uname -r
3.0.0-rc7

:-)

Cheers,
--
Luis Henriques