BeagleBone Black switching to 3.14 kernel

GoogleGroups
21

Hi Jason

Sorry to ask again. Will PREMPT be enabled in this ?

22

Full "preempt" no, not by default, but i'm testing "CONFIG_PREEMPT_VOLUNTARY"..

I'm still a little worried about the: "cost of slighly lower
throughput." for some applications we need all 1Ghz...

Regards,

23

Hi Jason

Sorry to ask again. Will PREMPT be enabled in this ?

Full "preempt" no, not by default, but i'm testing "CONFIG_PREEMPT_VOLUNTARY"..

I'm still a little worried about the: "cost of slighly lower
throughput." for some applications we need all 1Ghz...

I suspect most applications of BeagleBone Black will be more worried
about latency than throughput due to its "industrial" nature.
BeaglePilot, OpenROV, Lasersaur, MachineKit, Pocket NC, QuickBot, etc.
Sure, applications like Ninja Blocks, GrannyCam, and other "IoT"-ish
stuff might not care so much about latency, but they are probably more
interested in power management than absolutely highest performance.
Just my impression.

Would love to encourage more people to share what they are doing at
BeagleBone Black Project Spotlight: Shield I/O - BeagleBoard and to reach out for project spotlights
on Beagle Board Blog | Learn More about the lastes News and content to give us all more of an impression of
what people need and are doing.

I'm more worried about if anything breaks like what the BeaglePilot
folks have been reporting about some PRU driver issues related to
PREEMPT.

I will say that simply using the RT scheduler without PREEMPT still
makes things "pretty darn fast" (TM) as can be seen in the UCSD
BeagleMIP which runs the balancing algorithm as a normal Linux thread
w/o the PRUs, kernel task or PREEMPT.

24

Hi Robert

Ya I agree with Jason because if most of the time we are not running web servers using BBB but are interfacing BBB to the external world.
So i am more worried about latency than throughput.
Whats the risk of enabling CONFIG_PREEMPT in the kernel ?

Hi Jason, What were the issue that you mentioned were faced by BeaglePilot when using PRU ?

Thanks

25

Hi Robert

Ya I agree with Jason because if most of the time we are not running web
servers using BBB but are interfacing BBB to the external world.
So i am more worried about latency than throughput.
Whats the risk of enabling CONFIG_PREEMPT in the kernel ?

sudo apt-get update
sudo apt-get install linux-image-3.14.19-ti-r22

has: CONFIG_PREEMPT_VOLUNTARY

In the past, preempt broke a lot of things. So i'm always hesitant to
enable it by default across the board.

Hi Jason, What were the issue that you mentioned were faced by BeaglePilot
when using PRU ?

Regards,

26

PREEMPT has a tendency to tickle obscure bugs in non-SMP safe kernel
code. Many nasty bugs were uncovered as the PREEMPT code got merged
into the kernel. Now the core kernel is very SMP safe, but there are
still a lot of drivers (ie: "vendor-supplied code for single-core SoCs")
that are not SMP clean.

As multi-core ARM systems become more common, the situation should
improve (as it did with the x86 over time).

27

Hi Charles the BBB is a single core Soc

28

But, what about the poor panda/am43xx users who can also use this image. :wink:

Regards,

29

Hi Charles the BBB is a single core Soc

Actually, if you want to argue about it. The BBB has 3 cores.

30

I realize the BBB is a single-core SoC.

My point is enabling PREEMPT code in the kernel *REQUIRES* all kernel
code to be SMP safe (even when running on a single core!), which is why
this option causes stability issues.

As for the multi-core TI chips with similar drivers, it is not uncommon
for drivers to (mostly) work in a multi-core system without *REALLY*
being SMP safe. See the history of integrating the PREEMPT patch set to
the mainline kernel for a laundry list of obscure, hard-to-trace kernel
bugs that were uncovered in the process, even though Linux had been
running on multi-core x86 systems for quite some time.

31

Hi William

If you are counting the PRU yes, but technically they are not processors but more of peripherals/programmable controllers. Connect me if i am wrong.

32

Oh i see, i didn’t realize that you could use this image for panda. ok

33

There's other "processors" then the main Cortex-A8 core.. You got the
gpu and the Cortex-M3, both of which you can off load "tasks" too..
(The M3, does pm..)

Regards,

34

Thanks Charles for the reply.
I was trying to understand the complications of using CONFIG_PREEMPT.
But one final question, shouldn’t SMP be portable across platforms be it x86 or ARM ? If so the problems should be gone right ?

35

Hi William

I can understand the GPU but Cortex M3 ? Is it part of of the SOC ?
By PM did you mean Power Management ?

36

Yeap, it's inside and you have to talk/interact (load code) on it to
do lower power management.

Regards,

37

Hi William

If you are counting the PRU yes, but technically they are not
processors but
more of peripherals/programmable controllers. Connect me if i am wrong.

There's other "processors" then the main Cortex-A8 core.. You got the
gpu and the Cortex-M3, both of which you can off load "tasks" too..
(The M3, does pm..)

Yeah, but this is all unrelated to the stability issue. When Charles talks
about SMP safe, he is really talking about re-entrant safe code. With
PREEMPT, the big kernel lock was broken up to improve the Interrupt
latency. Now drivers have to ensure that variables/structures that are
accessed from both the kernel code and interrupt context are protected or
a race condition will occur. As Charles said, some of the third party
drivers haven¹t been updated to make them safe. Most of these are fixed by
following good programming practices that kernel gatekeepers enforce, but
old drivers only get fixed when they are updated.

Regards,
John

38

Thanks John for the explanation

39

But i am not able to find any references to it in the AM335x_TechnicalReferenceManual.

40

Hi Jason

Bit confused with the naming convnsion used in the link http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-08-05
The naming conventions that i am confused with are, basically what do they mean :

  1. Flasher: (lxde)
  2. microSD/Standalone: (lxde)
  3. Flasher: (console: 200Mb used)
  4. microSD/Standalone: (console: 200Mb used)

I understand that they have 3.14 kernel its just the naming conversion that confuses me.