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
