Hi,

Let me start in a bit unusual way :-). I do not like my "running things in
process mode" patch series  that much...
But I do think it should be merged. With the mixed mode.

The main goal of the patch series is to push the work regarding a proper
and consistent definition of some ODP low level concepts and objects. The
patch series makes things fail, hence pushing for defining and coding
things better, I hope.  Removing "provocative" things like the mixed mode
from it is just defeating the purpose of this series: I'll be happy to
remove it (and plenty of other things) when we know which well documented
definition/rule makes this code not relevant.
As long as we keep saying that odp threads could be indifferently  linux
processes or pthreads, I'll be thinking that this series should work,
inclusive any kind of mixed mode.

However, processes and threads are different things in linux, and I believe
this distinction should be kept within ODP: Trying to make processes behave
as pthreads for some ODP objects (such as addresses for shmem objects) does
not sound like a good idea to me. Yes, this can maybe be done with linux
-and even possibly without preallocating the memory-, but still, linux
creates 2 distinct virtual address spaces on fork() so why would ODP put
any exception to that?.
...And If we do want to create such exceptions (which I don't like),
shouln't ODP define its own concept of process and thread as it obviously
wouldn't match 100% the definition of the OS?

I do nevertheless definitively agree with Petri when saying that that ODP
applications should be given a way to "share pointers" between odpthreads.
Taking the "process only" behavior forcing every concurrent execution tasks
to use tricky offset calculation to find their data is too nasty and
inefficient.

I think this will boil down to 2 choices:
1) Take these object definitions from the OS and accept the OS rules.
2) Define our own ODP objects (and possibly defines our own rules)

1)Taking the OS definitions:
Choice 1) is consistent as long as we accept the OS rules. Taking that
choice would mean that any address remain valid within a process only:
shmem pointers will not be able to be shared between different processes: I
do not see that as a big problem as the applications can use pthreads if it
needs to share the same VA, or can fork() at a conveniant time. Moreover,
existing applications which should be ported to ODP are probably OK as they
would already be using pthreads/processes in the correct way.

A more tricky aspect of choice 1) is the development of ODP itself:
Operations involving many "ODPthreads" will have to cope with both
processes and threads possibly without a clear view of what is done by the
application. ( I guess in linux if getpid()==gettid() when calling
odp_init_local() one can assume safely that the app forked...?).
I guess it is doable: assuming all odpthreads are descendant of the
instanciation process, ODP can initially reserve shared memory in
odp_init_global() for its own purpose. It has a price: within ODP (and
anything external to the app itself, such as drivers) a common VA cannot be
assumed. ODP/drivers will have be prepared for an app fork at any time and
hence do its internal stuff as if pointers could not be shared (except
within the initially allocated memory). This will cost ODP performance.

Taking choice 1 probably also mean that shmen should no longer be part of
ODP: Allocating memory is as much an OS thing as forking a process... why
would shmem objects be ODP objects while ODP thread would not be?

2) Defining new ODP objects
I guess in this case, we'd have to create both ODP threads and ODP
processes objects and related usual methods. The advantage if this approach
is that ODP has more control of what is being done. It also allows for a
ODP definition of things (such as the above mentioned exception), if we
really want to...
It makes applications more portable (if ODP abstracts some of the common OS
functionality, the apps using these ODP api becomes OS agnostic).
As we already have done for shmem, ODP methods for odp threads and
processes could be provided to retrieve underlying OS stuff (such as PID...)

The problem of having to assume non common VA within ODP remains.

... and of course where should we stop wrapping the OS...?

3) There is a third alternative as well: stating that ODP is thread only
:-). No process, no problem?

Thank you for reading that far :-). waiting for your comments...

Christophe.
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to