Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

On 23 May 2016 at 10:16, Yi He wrote: > Hi, Christophe > > Here I met a difficulty, if I unified the API into > odph_odpthread_set_affinity(), > inside the function how can I determine whether the current context is a > pthread or process? So I cannot decide to call

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

On 23 May 2016 at 11:13, Yi He wrote: > Thanks very much Christophe > > This is great, I'll use this tech in > odph_odpthread_setaffinity()/getaffinity() APIs. > > Do you mean you think keeping underlying Linux pthread/process concepts > out of ODP thread concept is not good?

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

Thanks very much Christophe This is great, I'll use this tech in odph_odpthread_setaffinity()/getaffinity() APIs. Do you mean you think keeping underlying Linux pthread/process concepts out of ODP thread concept is not good? From many discussions I got a Feeling that by ODP thread we are really

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

Hi, I guess (not 100% sure if that civer all cases) if gettid() == getpid() you are on the main process thread. Having said that I do not like this solution very much: It really looks to me that we have a larger problem trying to keep these things out of ODP Something for ARCH call, maybe?

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

Hi, Christophe Here I met a difficulty, if I unified the API into odph_odpthread_set_affinity(), inside the function how can I determine whether the current context is a pthread or process? So I cannot decide to call sched_setaffinity() or pthread_setaffinity_np(). thanks and best regards, Yi

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

Hi, Christophe Yes, I'll apply your series and send a new one later. Best Regards, Yi On 23 May 2016 at 14:33, Christophe Milard wrote: > > > On 20 May 2016 at 10:48, Yi He wrote: > >> Set affinity to 1st available control cpu for all odp >>

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

On 20 May 2016 at 10:48, Yi He wrote: > Set affinity to 1st available control cpu for all odp > validation programs in odp_cunit_common library. > > Signed-off-by: Yi He > --- > helper/include/odp/helper/linux.h | 47 +++ >

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

Hi, Bill This is not introduced by this patch but in earlier code: *platform/linux-generic/odp_cpumask.c* *init_default_worker_cpumask()* *init_default_control_cpumask():* *...default mask initialization if not specified by odp_init_global()* */** * * If three or more CPUs, reserve CPU 0 for

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

This patch looks good, however when I run the thread helper test I get this output: bill@Ubuntu15:~/linaro/review/helper/test$ ./thread System can only support 2 threads and not the 16 requested default cpu mask: 0xC default num worker threads: 2 the first CPU: 2 new cpu

Re: [lng-odp] [PATCH] helper: linux: thread and process cpu affinity APIs

Hi, this is a proposal solution for ODP-427: how to guarantee cpu locality schematic of odp_cpu_cycles() and its relates. Discussions lead to the direction of "providing methods to set affinity in odp helper and do it by application on demand." So this is the patch: 1, Add APIs in helper/linux