v2 components naming

[machinekoder]

Does it have any disadvantages using the v2 components? If not why not make them the default and rename the old-style components to v1?

[ArcEye]

AFAIR before this stalled with the departure of the originator, there remained the issue of somehow tagging the v1 and v2 components, so that it was possible to know what type was loaded. There are also some holes in availability of v2 versions for all components I think.

The big problem is no-one uses them or has any use for them, so there is little impetus to continue them. The BBB with a 32 bit single core has no use for them. The push recently for low latency rt-preempt on amd64 with isolcpus and cpusets, negates multi-core and v2 in favour of low jitter.

It is only if there was extensive data streaming with multiple writers and readers on multi core machines, that it would come into its own in preventing the cache errors and data changing mid read etc. that it was conceived for.

[luminize]

On 10 Dec 2018, at 18:19, ArcEye notifications@github.com wrote:

The push recently for low latency rt-preempt on amd64 with isolcpus and cpusets, negates multi-core and v2 in favour of low jitter.

I’m not sure that we don’t have multicore capability. The isolcpus argument in this case is to prevent processes using these cpus during startup, so the cpusets can use these ‘clean’ cpus. The cpusets should be usable without isolcpus, right @zultron ?

I had some trouble defining a cpu for a thread with the cpu=cpu_nr argument when creating a thread and using isolcpus. I have not tested if defining a cpu to a thread will work with the recent cpusets work.

IMO it would be bad to lose multicore capabilities.

[zultron]

I'm sorry I wasn't following the multicore work, and don't understand v2 components or the issue at hand, but I can explain the cpuset feature.

In my experiments, I was unable to put a HAL thread on its own dedicated CPU with the newthread cpu=n CPU affinity feature alone, because there was nothing to stop the kernel from scheduling other processes on the same CPU. The two ways @Bas, @machinekoder and I found to reserve CPUs at all were the isolcpus kernel cmdline argument and the partrt script that uses cpuset cgroups. But CPU affinity can't cause a thread to cross isolcpus or cpuset boundaries and run on the reserved CPUS, while cpuset cgroups can cross either.

The CPU affinity argument does works well in concert with cpuset cgroups for further fine-grained control. For example, if you create (outside of HAL) a cpuset:/rt cgroup on CPUs 2 and 3, newthread cgname=/rt cpu=2 will put a thread on CPU 2, and newthread cgname=/rt cpu=3 will put a second thread on CPU 3.

[ArcEye]

@zultron OK, thanks for the 101, the last I heard it was being used with isolcpus

@luminize

IMO it would be bad to lose multicore capabilities.

We have not lost them, there has just been no appreciable demand for them.

In theory it would be better to use atomic operations for all uses. At the time we wrote them, the problem was that Wheezy did not really support them fully due to gcc version and that was the widely used distro. Now that Stretch and gcc 7 is becoming the default and a lot is backported to Jessie as well, that has changed somewhat.

There still remains the issue of our main user base appearing to be plastic squirters using MK because it is free and can run on little single core ARM boards, all of whom have no use for it.

The immediate requirement to fully implement v2 multicore capabilities is: 1) Ensure ALL relevant components / drivers etc. support it in a v2 version 2) Find a way of being able to tell what type of component is loaded and control the loading.

The actual components do not differ much, except that they use pin_ptrs instead of de-referencing the actual pins to read/write and they use atomic get/set accessors. I wrote macros for those which are quite simple to use.

[zultron]

Thinking about this one:

2. Find a way of being able to tell what type of component is loaded and control the loading.

I think the component type could be recorded in the .rtapi_export, .modinfo or its own ELF segment? When rtapi_app loads a component, it could check the component's type from there and treat it accordingly.

[cerna]

Just to register a token: I was thinking about hacking into V2 the support for multi-flavor function hooks. The idea is similar to current mk-single-module for when the call (like in hostmot ethernet driver) would cause non-realtime aligned behavior (like context switch). Otherwise there would be need for multiple .so for some HAL modules.

(Thinking about it there still might be need for multiple .so. The "flavoring" of HAL components never really was 100%.)

[ArcEye]

I think @mhaberler was aiming towards direct detection from the ELF header at one time, but the tools are already there via module tagging.

instcomp adds HC_INSTANTIABLE tags to show the module is instantiated https://github.com/machinekit/machinekit-hal/blob/master/src/hal/utils/instcomp.g#L392

It also adds a HC_SMP_SAFE tag if pin_ptrs are in use, which is v2 only https://github.com/machinekit/machinekit-hal/blob/master/src/hal/utils/instcomp.g#L397

Between the 2 it should be easy to determine which module is in use. Example parsing of the tags here (note just basic instantiatable property at present) https://github.com/machinekit/machinekit-hal/blob/master/src/hal/utils/halcmd_commands.c#L1290

The question switched towards the end, to naming and whether there should be 2 dirs with the 2 types of modules, or whether all modules should actually be v2, irrespective of whether the computers architecture could take advantage of the SMP aspects and just have SMP safe and atomic operations for all.

Since the demise of Wheezy, the compilers C11 implementation ceases to be a limiting factor in atomic ops.

[zultron]

Just to register a token: I was thinking about hacking into V2 the support for multi-flavor function hooks. The idea is similar to current mk-single-module for when the call (like in hostmot ethernet driver) would cause non-realtime aligned behavior (like context switch). Otherwise there would be need for multiple .so for some HAL modules.

I'm very interested to hear what you're thinking about this. Can you open a separate issue for it (with links back to #227) and more details, especially about your use case?

[zultron]

@ArcEye Thanks for the history lesson. That helps a lot to understand the problem both here and in #104.

The question switched towards the end, to naming and whether there should be 2 dirs with the 2 types of modules, or whether all modules should actually be v2, irrespective of whether the computers architecture could take advantage of the SMP aspects and just have SMP safe and atomic operations for all.

Since the demise of Wheezy, the compilers C11 implementation ceases to be a limiting factor in atomic ops.

So, I'm still not caught up on these issues, but I do prefer getting the better comp without adding a v2 suffix, and I can't help (see #227) reading #104 under the light of favoring all modules in a single directory.

@ArcEye, are these 64-bit atomic ops actually in the v1 comp HAL code today, or is there still work needed to add them?

FWIW, I don't see any big emergency here; I'm just trying to fill my curiosity and this gap in my understanding.

[ArcEye]

@ArcEye, are these 64-bit atomic ops actually in the v1 comp HAL code today, or is there still work needed to add them?

No, the atomic operations require pin_ptrs instead of pins and then use the assessor functions to get and set the values. These guarantee that the operation will complete, so there is no chance of another actor changing a value at the same time. Only the v2 components do this.

There is no point adding anything to v1, you would just get v2, which already exist.

The question really is do we do away with v1 and just accept that the features v2 bring will be redundant on some architectures and quite frankly for the overwhelming majority of usages.

Only on cached multi-core machines with several processes liable to access the same pins, does the v2 come into its own.