HI Ralf, Could you please keep your posts on the same thread so it makes it possible for others to follow, there are a great many posts that get posted on osg-users and unless you keep to the thread basically it becomes unmanageable for us to follow things.
And when you say Hi... and he disagress with you, who do you mean here? Please make your posts human readable as if you want assistance on any on this topics then you need others to be able to follow easily. Robert. On Tue, Oct 14, 2008 at 5:25 PM, Ralph R. Peters <[EMAIL PROTECTED]> wrote: > Hi, > > I spent some time talking to jakub who runs the gcc forum and he disagrees > with you. A digest follows of our exchanges and a link to the entire > thread. > > A related problem may be that the test for pthread_setaffinity_np fails in > CMake. See my second post from yesterday. > > Ralph > > > > Initially, I sent email to [EMAIL PROTECTED] The entire thread may > be found at: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586 > > After a number of emails jakub responded: > > ************************************************************************* (A > strace -f -e sched_getaffinity dump by me yielded the following: > > jakub responded: > > sched_getaffinity(3502, 128, { ff, 0, 0, 0 }) = 32 > .... > sched_getaffinity(3502, 128, { 1, 0, 0, 0 }) = 32 > ... > sched_getaffinity(3502, 128, { 1, 0, 0, 0 }) = 32 > > Shows that the process originally was bound to any of the 8 CPUs (mask > 0xff), > but after a while it got confined only to the first CPU. The question is > what > has done that. You can look for sched_setaffinity syscall in the strace > dump, > then either from the surrounding syscalls or under debugger find out where > sched_setaffinity or pthread_setaffinity_np functions have been called from > or if the program invokes the syscall directly, without calling a > libc/libpthread function. > > **************************************************************************** > I responded: > Hi Jakub, > > I did as you asked and get: > > sched_setaffinity(24094, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0 }) = 0 > > Its buried in other "startup" code: > > .............................. > NOTE: usg::Scene using usg default data file path list > > path = > .:/usr/local/share/OpenSceneGraph/data:/usr/local/share/OpenSceneGraph/data/Env:/usr/local/share/OpenSceneGraph/data/fonts:/usr/local/share/OpenSceneGraph/data/Images:/usr/share/OpenSceneGraph/data:/usr/share/OpenSceneGraph/data/Env:/usr/share/OpenSceneGraph/data/fonts:/usr/share/OpenSceneGraph/data/Images > > camera number: 0 > > sched_setaffinity(24094, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, > 0, 0 }) = 0 > > INFO> navigation mode set to umbra > > Warning: font file "fonts/arial.ttf" not found. > > Setting savConfigCB to '::guiWrapper saveConfig' > > sLoadFile filename:/home/vision_data/geometry_objects/test.cdf fileType: > lineRowCnt=-1 lineColCnt=-1 > > std::string UmbModCDFDataSet::LoadFile(const s...... > ................................... > > I suppose that this means that something in Tcl, OpenScenegraph, umbra, my > own rwm is setting the following software to run on only one processor. I > ran a strace -f to get a full "dump" and found that it occurs between 2 > "open(library)" calls. I backtracked to OpenSceneGraph to find one > possibility: > > [EMAIL PROTECTED] src]$ pwd > > /usr/local/src/OpenSceneGraph-2.4.0/src > > [EMAIL PROTECTED] src]$ find . -exec grep -n -H sched_setaffinity {} \; > > ./OpenThreads/pthreads/CMakeLists.txt:73: sched_setaffinity( 0, > sizeof(cpumask), &cpumask ); > > ./OpenThreads/pthreads/CMakeLists.txt:83: sched_setaffinity( 0, &cpumask ); > > ./OpenThreads/pthreads/PThread.c++:135: sched_setaffinity( 0, > sizeof(cpumask), &cpumask ); > > ./OpenThreads/pthreads/PThread.c++:137: sched_setaffinity( 0, > &cpumask ); > > ./OpenThreads/pthreads/PThread.c++:549: sched_setaffinity( 0, > sizeof(cpumask), &cpumask ); > > ./OpenThreads/pthreads/PThread.c++:551: sched_setaffinity( 0, > &cpumask ); > > ./OpenThreads/pthreads/PThread.c++:984: sched_setaffinity( 0, > sizeof(cpumask), &cpumask ); > > ./OpenThreads/pthreads/PThread.c++:986: sched_setaffinity( 0, > &cpumask ); > > ./OpenThreads/pthreads/GNUmakefile:43:ifeq > ($(COMPILE_USING_TWO_PARAM_sched_setaffinity),yes) > > ./OpenThreads/pthreads/GNUmakefile:44:DEF += > -DCOMPILE_USING_TWO_PARAM_sched_setaffinity > > [EMAIL PROTECTED] src]$ > > This looks like a possibility for the source of my problem or not? > Can I make my own call to sched_setaffinity? There is, of course, always > the possibility of causing problems. > > Ralph > > *************************************************************************** > jakub responded: > > - > ------ Comment #9 from jakub at gcc dot gnu dot org 2008-10-13 17:52 > ------- > Yes, that certainly is the source of your problems. You could call > sched_setaffinity or pthread_sched_setaffinity in your program before > entering > an OpenMP region, guess you should also find out why does that library > confine > the thread to just one CPU. > Anyway, closing this, as it clearly is not a GCC/libgomp bug. > *************************************************************************** > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
