Hi all,
I have an agenda conflict and won't be able to join the call today,
however I am interested in the subject. I can't find this patch in the
ML nor in the master or api-next odp git branches, could you point me to
it, or even better, post it on the ML for discussion?
I am a bit worried about the inclusion of cgroups into ODP.
Thanks,
ben
On 05/26/2015 02:28 PM, Mike Holmes wrote:
Radu
Can you join the opencall today to discuss this ?
http://www.uberconference.com/opendataplane 4.00pm GMT
Mike
On 25 May 2015 at 04:37, Radu-Andrei Bulie <[email protected]
<mailto:[email protected]>> wrote:
Hi,____
__ __
The patch mentioned in the title is somehow related with the idea of
odp threads isolation, I mean the odp data path threads.____
I am not aware of any discussions regarding the cgroups to provide
odp threads isolation nor some updates in the odp____
API that will provide an integration with the cgroup library and
cpusets usage.____
As it is stated in the ODP documentation the odp data path threads
are not controlled by the Linux scheduler - instead there is____
a HW SoC level scheduler that manages them (or a specialized SW).
This implies that there is not any strict dependency in isolating
the odp threads by the rest____
of the linux processes.____
The problem introduced by this patch, on our platform, is that it
restricts the usage of all cores available on the default scheduling
domain provided by Linux.____
And when I say all cores I include here the cores which are isolated
from rest and do not participate in the load balancing scheme of the
scheduler.(this is achieved____
with the kernel boot time isolcpus). This cores will be used for the
odp data path threads and will be assigned explicitly at threads'
creation time.____
Thus the Linux scheduler will load balance processes(threads) on the
non-isolated cores.(these will be the odp control path threads).____
The exact problem of the patch is that - to determine the number of
cores available for threads' creation - it uses the
pthread_getaffinity_np function (and not____
_SC_NPROCESSORS_ONLN as before) which will return all the cores on
which a threads is eligible to run - that is all the cores that
participate in the Linux ____
load balancing scheme. In this situation(with this patch), on our
platform, we are able to create, for example, just one thread - on
core 0, which is used for control, because____
the other cores 1..n which are isolated, are not visible using the
function mentioned above.(and as I said they will be used for the
fast path processing)____
As a conclusion, an action should be taken regarding the mentioned
patch.____
__ __
__ __
Regards,____
__ __
Radu____
_______________________________________________
lng-odp mailing list
[email protected] <mailto:[email protected]>
https://lists.linaro.org/mailman/listinfo/lng-odp
--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM SoCs
__
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
--
Benoît GANNE
Field Application Engineer, Kalray
+33 (0)648 125 843
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
