* Why is taskset still not in util-linux? @ 2020-03-01 21:46 Eliot Moss 2020-03-04 13:32 ` Mark Geisert 0 siblings, 1 reply; 28+ messages in thread From: Eliot Moss @ 2020-03-01 21:46 UTC (permalink / raw) To: cygwin Dear cygwin-ers -- Something I had asked about a while ago was the absence os taskset in cygwin's util-linux. At the time, it was pointed out that the necessary get/set affinity library/system calls were not yet supported. These were added a while ago, so it would seem that taskset ought to work. In fact, I think someone got it going on their own. Can we add it to util-linux now, officially? I think this was intended but perhaps was overlooked or something. Regards - Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-01 21:46 Why is taskset still not in util-linux? Eliot Moss @ 2020-03-04 13:32 ` Mark Geisert 2020-03-16 23:34 ` Mark Geisert 0 siblings, 1 reply; 28+ messages in thread From: Mark Geisert @ 2020-03-04 13:32 UTC (permalink / raw) To: cygwin Eliot Moss wrote: > > Dear cygwin-ers -- > > Something I had asked about a while ago was the absence os taskset in cygwin's > util-linux. At the time, it was pointed out that the necessary get/set > affinity library/system calls were not yet supported. These were added a > while ago, so it would seem that taskset ought to work. In fact, I think > someone got it going on their own. Can we add it to util-linux now, > officially? I think this was intended but perhaps was overlooked or > something. Report noted; thanks. A solution is being worked. ..mark -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-04 13:32 ` Mark Geisert @ 2020-03-16 23:34 ` Mark Geisert 2020-03-19 10:14 ` Eliot Moss 0 siblings, 1 reply; 28+ messages in thread From: Mark Geisert @ 2020-03-16 23:34 UTC (permalink / raw) To: cygwin Mark Geisert wrote: > Eliot Moss wrote: >> >> Dear cygwin-ers -- >> >> Something I had asked about a while ago was the absence os taskset in cygwin's >> util-linux. At the time, it was pointed out that the necessary get/set >> affinity library/system calls were not yet supported. These were added a >> while ago, so it would seem that taskset ought to work. In fact, I think >> someone got it going on their own. Can we add it to util-linux now, >> officially? I think this was intended but perhaps was overlooked or >> something. > > Report noted; thanks. A solution is being worked. There's been no forward progress on this. If you're comfortable getting the util-linux source package through Cygwin setup*.exe, you can follow the steps shown in https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to build (with cygport) a local copy of util-linux that includes a taskset.exe you can move into /usr/local/bin, for example. You might try that route if you're up for it. Feel free to ask questions here if you hit a snag. HTH, ..mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-16 23:34 ` Mark Geisert @ 2020-03-19 10:14 ` Eliot Moss 2020-03-19 10:41 ` Marco Atzeri 2020-03-19 23:29 ` Mark Geisert 0 siblings, 2 replies; 28+ messages in thread From: Eliot Moss @ 2020-03-19 10:14 UTC (permalink / raw) To: Mark Geisert, cygwin On 3/16/2020 7:34 PM, Mark Geisert wrote: > Mark Geisert wrote: >> Eliot Moss wrote: >>> >>> Dear cygwin-ers -- >>> >>> Something I had asked about a while ago was the absence os taskset in cygwin's >>> util-linux. At the time, it was pointed out that the necessary get/set >>> affinity library/system calls were not yet supported. These were added a >>> while ago, so it would seem that taskset ought to work. In fact, I think >>> someone got it going on their own. Can we add it to util-linux now, >>> officially? I think this was intended but perhaps was overlooked or >>> something. >> >> Report noted; thanks. A solution is being worked. > > There's been no forward progress on this. If you're comfortable getting the util-linux source > package through Cygwin setup*.exe, you can follow the steps shown in > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to build (with cygport) a local copy > of util-linux that includes a taskset.exe you can move into /usr/local/bin, for example. > > You might try that route if you're up for it. Feel free to ask questions here if you hit a snag. > HTH, Thank you, Mark. I decided to give it a try and got some distance, but hit a snag. First, I had to change configure.ac to add control to disable ionice (Cygwin does not support a required syscall) while still trying to build taskset. Previously taskset and ionice (and one other program) were controlled by the single --enable-schedutils. Now, including sched.h does not provide the prototypes for sched_getaffinity, etc. I found a previous post that suggests we need to do -D_GNU_SOURCE for it to work. I am not sure of the best place to stick that, but I will see about maybe a one line patch to taskset.c or something. Regards - Eliot ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-19 10:14 ` Eliot Moss @ 2020-03-19 10:41 ` Marco Atzeri 2020-03-19 23:29 ` Mark Geisert 1 sibling, 0 replies; 28+ messages in thread From: Marco Atzeri @ 2020-03-19 10:41 UTC (permalink / raw) To: cygwin Am 19.03.2020 um 11:14 schrieb Eliot Moss: > On 3/16/2020 7:34 PM, Mark Geisert wrote: > > Mark Geisert wrote: > >> Eliot Moss wrote: > >>> > >>> Dear cygwin-ers -- > >>> > >>> Something I had asked about a while ago was the absence os taskset > in cygwin's > >>> util-linux. At the time, it was pointed out that the necessary > get/set > >>> affinity library/system calls were not yet supported. These were > added a > >>> while ago, so it would seem that taskset ought to work. In fact, I > think > >>> someone got it going on their own. Can we add it to util-linux now, > >>> officially? I think this was intended but perhaps was overlooked or > >>> something. > >> > >> Report noted; thanks. A solution is being worked. > > > > There's been no forward progress on this. If you're comfortable > getting the util-linux source > > package through Cygwin setup*.exe, you can follow the steps shown in > > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to > build (with cygport) a local copy > > of util-linux that includes a taskset.exe you can move into > /usr/local/bin, for example. > > > > You might try that route if you're up for it. Feel free to ask > questions here if you hit a snag. > > HTH, > > Thank you, Mark. I decided to give it a try and got some distance, but > hit a snag. > > First, I had to change configure.ac to add control to disable ionice > (Cygwin > does not support a required syscall) while still trying to build taskset. > Previously taskset and ionice (and one other program) were controlled by > the > single --enable-schedutils. > > Now, including sched.h does not provide the prototypes for > sched_getaffinity, > etc. I found a previous post that suggests we need to do -D_GNU_SOURCE > for it > to work. I am not sure of the best place to stick that, but I will see > about > maybe a one line patch to taskset.c or something. > > Regards - Eliot one brutal solution I recently used cygconf echo "defining _GNU_SOURCE on config.h" echo "#define _GNU_SOURCE 1" >> config.h cygmake the patch approach is usually restricted to a portion of the code or a general header. May be there is already something like that in the code, or you can add a similar stuff #if defined(__linux__) || defined(__CYGWIN__) # ifndef _GNU_SOURCE # define _GNU_SOURCE # endif ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-19 10:14 ` Eliot Moss 2020-03-19 10:41 ` Marco Atzeri @ 2020-03-19 23:29 ` Mark Geisert 2020-03-20 5:54 ` Mark Geisert 1 sibling, 1 reply; 28+ messages in thread From: Mark Geisert @ 2020-03-19 23:29 UTC (permalink / raw) To: moss, cygwin Eliot Moss wrote: > On 3/16/2020 7:34 PM, Mark Geisert wrote: > > Mark Geisert wrote: > >> Eliot Moss wrote: > >>> > >>> Dear cygwin-ers -- > >>> > >>> Something I had asked about a while ago was the absence os taskset in cygwin's > >>> util-linux. At the time, it was pointed out that the necessary get/set > >>> affinity library/system calls were not yet supported. These were added a > >>> while ago, so it would seem that taskset ought to work. In fact, I think > >>> someone got it going on their own. Can we add it to util-linux now, > >>> officially? I think this was intended but perhaps was overlooked or > >>> something. > >> > >> Report noted; thanks. A solution is being worked. > > > > There's been no forward progress on this. If you're comfortable getting the > util-linux source > > package through Cygwin setup*.exe, you can follow the steps shown in > > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to build > (with cygport) a local copy > > of util-linux that includes a taskset.exe you can move into /usr/local/bin, > for example. > > > > You might try that route if you're up for it. Feel free to ask questions > here if you hit a snag. > > HTH, > > Thank you, Mark. I decided to give it a try and got some distance, but hit a snag. > > First, I had to change configure.ac to add control to disable ionice (Cygwin > does not support a required syscall) while still trying to build taskset. > Previously taskset and ionice (and one other program) were controlled by the > single --enable-schedutils. > > Now, including sched.h does not provide the prototypes for sched_getaffinity, > etc. I found a previous post that suggests we need to do -D_GNU_SOURCE for it > to work. I am not sure of the best place to stick that, but I will see about > maybe a one line patch to taskset.c or something. Rats. Sorry you've hit some snags. Are you compiling directly with 'make' or the preferred 'cygport util-linux.cygport build'? With the latter I didn't need to make any changes to the source tree; all mods were accomplished with the new patch file and changes to util-linux.cygport itself. ..mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-19 23:29 ` Mark Geisert @ 2020-03-20 5:54 ` Mark Geisert 2020-03-20 10:29 ` Eliot Moss ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Mark Geisert @ 2020-03-20 5:54 UTC (permalink / raw) To: moss, cygwin Mark Geisert wrote: > Eliot Moss wrote: >> On 3/16/2020 7:34 PM, Mark Geisert wrote: >> > Mark Geisert wrote: >> >> Eliot Moss wrote: >> >>> >> >>> Dear cygwin-ers -- >> >>> >> >>> Something I had asked about a while ago was the absence os taskset in >> cygwin's >> >>> util-linux. At the time, it was pointed out that the necessary get/set >> >>> affinity library/system calls were not yet supported. These were added a >> >>> while ago, so it would seem that taskset ought to work. In fact, I think >> >>> someone got it going on their own. Can we add it to util-linux now, >> >>> officially? I think this was intended but perhaps was overlooked or >> >>> something. >> >> >> >> Report noted; thanks. A solution is being worked. >> > >> > There's been no forward progress on this. If you're comfortable getting >> the util-linux source >> > package through Cygwin setup*.exe, you can follow the steps shown in >> > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to build >> (with cygport) a local copy >> > of util-linux that includes a taskset.exe you can move into /usr/local/bin, >> for example. >> > >> > You might try that route if you're up for it. Feel free to ask questions >> here if you hit a snag. >> > HTH, >> >> Thank you, Mark. I decided to give it a try and got some distance, but hit a >> snag. >> >> First, I had to change configure.ac to add control to disable ionice (Cygwin >> does not support a required syscall) while still trying to build taskset. >> Previously taskset and ionice (and one other program) were controlled by the >> single --enable-schedutils. >> >> Now, including sched.h does not provide the prototypes for sched_getaffinity, >> etc. I found a previous post that suggests we need to do -D_GNU_SOURCE for it >> to work. I am not sure of the best place to stick that, but I will see about >> maybe a one line patch to taskset.c or something. > > Rats. Sorry you've hit some snags. Are you compiling directly with 'make' or > the preferred 'cygport util-linux.cygport build'? With the latter I didn't need > to make any changes to the source tree; all mods were accomplished with the new > patch file and changes to util-linux.cygport itself. I've reproduced your snags. It/they are due to my having forgotten another tiny update that should have been part of the 2.33.1-cygwin-cpuset.patch file. If you 'echo "#define SYS_sched_getaffinity 42" > /usr/local/include/sys/syscall.h' and then back out your other fix attempts, the build using cygport should work. ..mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-20 5:54 ` Mark Geisert @ 2020-03-20 10:29 ` Eliot Moss 2020-03-20 21:42 ` Andrey Repin 2020-03-20 13:39 ` Yaakov Selkowitz 2020-03-21 4:59 ` Eliot Moss 2 siblings, 1 reply; 28+ messages in thread From: Eliot Moss @ 2020-03-20 10:29 UTC (permalink / raw) To: cygwin On 3/20/2020 1:54 AM, Mark Geisert wrote: > Mark Geisert wrote: >> Eliot Moss wrote: >> Rats. Sorry you've hit some snags. Are you compiling directly with 'make' or the preferred >> 'cygport util-linux.cygport build'? With the latter I didn't need to make any changes to the >> source tree; all mods were accomplished with the new patch file and changes to util-linux.cygport >> itself. > > I've reproduced your snags. It/they are due to my having forgotten another tiny update that should > have been part of the 2.33.1-cygwin-cpuset.patch file. If you 'echo "#define SYS_sched_getaffinity > 42" > /usr/local/include/sys/syscall.h' and then back out your other fix attempts, the build using > cygport should work. What an amusing hack! I especially like the sensibility of 42! :-) I will try this. When I built it last night, I got a successful compile, but it didn't do anything. For example, taskset 1 ls did not output _anything_ -- no error message and no ls output :-( ... It will be the weekend here in Australia (I'm visiting, and wondering about exactly how and when I will get home) so maybe I'll play with it some more on Saturday ... Regards - Eliot ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-20 10:29 ` Eliot Moss @ 2020-03-20 21:42 ` Andrey Repin 0 siblings, 0 replies; 28+ messages in thread From: Andrey Repin @ 2020-03-20 21:42 UTC (permalink / raw) To: Eliot Moss, cygwin Greetings, Eliot Moss! >> I've reproduced your snags. It/they are due to my having forgotten another >> tiny update that should have been part of the 2.33.1-cygwin-cpuset.patch >> file. If you >> 'echo "#define SYS_sched_getaffinity 42" > /usr/local/include/sys/syscall.h' >> and then back out your other fix attempts, the build using cygport should work. > What an amusing hack! I especially like the sensibility of 42! :-) Because that's THE ANSWER! > I will try this. When I built it last night, I got a successful compile, > but it didn't do anything. For example, taskset 1 ls did not output > _anything_ -- no error message and no ls output :-( ... > It will be the weekend here in Australia (I'm visiting, and wondering about > exactly how and when I will get home) so maybe I'll play with it some more > on Saturday ... -- With best regards, Andrey Repin Saturday, March 21, 2020 0:41:58 Sorry for my terrible english... ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-20 5:54 ` Mark Geisert 2020-03-20 10:29 ` Eliot Moss @ 2020-03-20 13:39 ` Yaakov Selkowitz 2020-03-21 1:46 ` Eliot Moss 2020-03-21 4:59 ` Eliot Moss 2 siblings, 1 reply; 28+ messages in thread From: Yaakov Selkowitz @ 2020-03-20 13:39 UTC (permalink / raw) To: cygwin On Thu, 2020-03-19 at 22:54 -0700, Mark Geisert wrote: > Mark Geisert wrote: > > Eliot Moss wrote: > > > On 3/16/2020 7:34 PM, Mark Geisert wrote: > > > > Mark Geisert wrote: > > > >> Eliot Moss wrote: > > > >>> > > > >>> Dear cygwin-ers -- > > > >>> > > > >>> Something I had asked about a while ago was the absence os taskset in > > > cygwin's > > > >>> util-linux. At the time, it was pointed out that the necessary get/set > > > >>> affinity library/system calls were not yet supported. These were added a > > > >>> while ago, so it would seem that taskset ought to work. In fact, I think > > > >>> someone got it going on their own. Can we add it to util-linux now, > > > >>> officially? I think this was intended but perhaps was overlooked or > > > >>> something. > > > >> > > > >> Report noted; thanks. A solution is being worked. > > > > > > > > There's been no forward progress on this. If you're comfortable getting > > > the util-linux source > > > > package through Cygwin setup*.exe, you can follow the steps shown in > > > > https://cygwin.com/pipermail/cygwin-apps/2020-March/039855.html to build > > > (with cygport) a local copy > > > > of util-linux that includes a taskset.exe you can move into /usr/local/bin, > > > for example. > > > > > > > > You might try that route if you're up for it. Feel free to ask questions > > > here if you hit a snag. > > > > HTH, > > > > > > Thank you, Mark. I decided to give it a try and got some distance, but hit a > > > snag. > > > > > > First, I had to change configure.ac to add control to disable ionice (Cygwin > > > does not support a required syscall) while still trying to build taskset. > > > Previously taskset and ionice (and one other program) were controlled by the > > > single --enable-schedutils. > > > > > > Now, including sched.h does not provide the prototypes for sched_getaffinity, > > > etc. I found a previous post that suggests we need to do -D_GNU_SOURCE for it > > > to work. I am not sure of the best place to stick that, but I will see about > > > maybe a one line patch to taskset.c or something. > > > > Rats. Sorry you've hit some snags. Are you compiling directly with 'make' or > > the preferred 'cygport util-linux.cygport build'? With the latter I didn't need > > to make any changes to the source tree; all mods were accomplished with the new > > patch file and changes to util-linux.cygport itself. > > I've reproduced your snags. It/they are due to my having forgotten another tiny > update that should have been part of the 2.33.1-cygwin-cpuset.patch file. If > you 'echo "#define SYS_sched_getaffinity 42" > /usr/local/include/sys/syscall.h' > and then back out your other fix attempts, the build using cygport should work. Cygwin doesn't support syscalls. I'd be very wary of any code which is conditional on any #ifdef SYS_*. -- Yaakov ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-20 13:39 ` Yaakov Selkowitz @ 2020-03-21 1:46 ` Eliot Moss 2020-03-21 8:37 ` Mark Geisert 0 siblings, 1 reply; 28+ messages in thread From: Eliot Moss @ 2020-03-21 1:46 UTC (permalink / raw) To: cygwin On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote: > Cygwin doesn't support syscalls. I'd be very wary of any code which is > conditional on any #ifdef SYS_*. Of course. AFAICT taskset does not need the syscall, it just needs the library call to work. Asking about the syscall is, I suppose, a kind of Linux shorthand to see if something is supported on the particular platform. Mark's suggestion of providing a fake definition of that syscall definition is a workaround that may disturb the util-linux sources the least. Regards - Eliot ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 1:46 ` Eliot Moss @ 2020-03-21 8:37 ` Mark Geisert 2020-03-21 10:24 ` Eliot Moss 2020-03-22 20:09 ` Yaakov Selkowitz 0 siblings, 2 replies; 28+ messages in thread From: Mark Geisert @ 2020-03-21 8:37 UTC (permalink / raw) To: moss, cygwin Eliot Moss wrote: > On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote: > > > Cygwin doesn't support syscalls. I'd be very wary of any code which is > > conditional on any #ifdef SYS_*. > > Of course. AFAICT taskset does not need the syscall, it just needs the > library call to work. Asking about the syscall is, I suppose, a kind of Linux > shorthand to see if something is supported on the particular platform. Mark's > suggestion of providing a fake definition of that syscall definition is a > workaround that may disturb the util-linux sources the least. What I did here was definitely a hack. I'm not sure it's the best solution. I fully concur with Yaakov's warning. There's two levels to syscalls as seen in programs like taskset. On one level, configure checks whether a particular syscall exists on the compiling machine because different Linux kernels have different sets of syscalls. On the second level, the program actually uses a call named syscall() to call into specific kernel routines. On Cygwin, what to do about programs that assume they're running on Linux and so make use of the Linux syscall feature? We could dummy up a sys/syscall.h but implementing a full syscall() interface would be a lot of work and do nothing but slow down programs making heavy use of it; it adds a layer of indirection. Yaakov, do you have a general strategy for dealing with syscall usage when you've come across it in all the porting you've done? Cygwin-specific patch? ..mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 8:37 ` Mark Geisert @ 2020-03-21 10:24 ` Eliot Moss 2020-03-21 11:07 ` Eliot Moss 2020-03-22 20:09 ` Yaakov Selkowitz 1 sibling, 1 reply; 28+ messages in thread From: Eliot Moss @ 2020-03-21 10:24 UTC (permalink / raw) To: cygwin Dear Mark - I am confused by how your build goes through when configure detects the ionice does not have the ioprio_set/get calls that it needs. In my case configure stops at that point. That was why I made a patch to configure.ac so that cygport could explicitly exclude ionice. At the moment, I am seeing what happens if I add more "fake" syscalls to syscall.h for those two calls. The configure goes through (as expected), but of course ionice fails to link (no 'syscall" function). If I revert to having only SYS_sched_getaffinity defined, configure stops with: checking for syscall ioprio_set... no configure: WARNING: Unable to detect syscall ioprio_set. configure: error: ionice selected but ioprio_set syscall not found *** ERROR: configure failed That why I think I/we need some kind of patch to configure.ac. How does your build manage to continue? I am working from the Cygwin util-linux-2.33.1-1 source package. Is that the correct one? Also, I am in the x86-64 world for all this. Eliot ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 10:24 ` Eliot Moss @ 2020-03-21 11:07 ` Eliot Moss 2020-03-21 13:29 ` Marco Atzeri 2020-03-21 14:26 ` Roumen Petrov 0 siblings, 2 replies; 28+ messages in thread From: Eliot Moss @ 2020-03-21 11:07 UTC (permalink / raw) To: cygwin So here's a thing, though I don't understand it: In addition the build/taskset.exe, there's a build/.libs/taskset.exe. If I install the latter in /usr/bin/.libs/taskset.exe, then /usr/bin/taskset works. In fact, it seems that the version in .libs is the "real" program and /usr/bin/taskset is some kind of trampoline (?) to it? In fact, a stripped version of build/.libs/taskset installed in /usr/bin works just fine. There must be some kind of build and install convention going on that I am not familiar with. (I'm not familiar with a lot of these build processes, actually.) Best - Eliot ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 11:07 ` Eliot Moss @ 2020-03-21 13:29 ` Marco Atzeri 2020-03-21 14:26 ` Roumen Petrov 1 sibling, 0 replies; 28+ messages in thread From: Marco Atzeri @ 2020-03-21 13:29 UTC (permalink / raw) To: cygwin Am 21.03.2020 um 12:07 schrieb Eliot Moss: > So here's a thing, though I don't understand it: > > In addition the build/taskset.exe, there's a build/.libs/taskset.exe. that is usually the unstripped version > If I install the latter in /usr/bin/.libs/taskset.exe, then > /usr/bin/taskset > works. In fact, it seems that the version in .libs is the "real" program > and /usr/bin/taskset is some kind of trampoline (?) to it? it is the libtool wrapper, infact it is linked only to cygwin1.dll $ objdump -x .libs/gprof.exe | grep "DLL Name" DLL Name: cygwin1.dll DLL Name: cygintl-8.dll DLL Name: KERNEL32.dll $ objdump -x gprof.exe | grep "DLL Name" DLL Name: cygwin1.dll DLL Name: KERNEL32.dll $ strings gprof.exe | grep ".libs" ./.libs/lt-gprof.c # gprof - temporary wrapper script for .libs/gprof ... > > In fact, a stripped version of build/.libs/taskset installed in /usr/bin > works just fine. There must be some kind of build and install convention > going on that I am not familiar with. (I'm not familiar with a lot of > these build processes, actually.) > > Best - Eliot I also forget the details from time to time... Marco ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 11:07 ` Eliot Moss 2020-03-21 13:29 ` Marco Atzeri @ 2020-03-21 14:26 ` Roumen Petrov 2020-03-21 23:13 ` Eliot Moss 1 sibling, 1 reply; 28+ messages in thread From: Roumen Petrov @ 2020-03-21 14:26 UTC (permalink / raw) To: cygwin Eliot Moss wrote: > So here's a thing, though I don't understand it: > > In addition the build/taskset.exe, there's a build/.libs/taskset.exe. > If I install the latter in /usr/bin/.libs/taskset.exe, then /usr/bin/taskset > works. In fact, it seems that the version in .libs is the "real" program > and /usr/bin/taskset is some kind of trampoline (?) to it? Libtool wrapper is shell script on Unix/Linux and executable on Microsoft Windows OS. Goal of "wrapper" is to prepare environment in the way that allows to run real executable without installation. Project that creates just one executable is not the beast sample but think for a library project and a bundle of tests (executable). All tests must load library from build tree. > > In fact, a stripped version of build/.libs/taskset installed in /usr/bin > works just fine. There must be some kind of build and install convention > going on that I am not familiar with. (I'm not familiar with a lot of > these build processes, actually.) I think that in some cases this executable has to be relinked. Definitely not on Microsoft Windows OS. So on cygwin it is "final" executable. > > Best - Eliot Regards, Roumen ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 14:26 ` Roumen Petrov @ 2020-03-21 23:13 ` Eliot Moss 2020-03-22 4:10 ` Eliot Moss 0 siblings, 1 reply; 28+ messages in thread From: Eliot Moss @ 2020-03-21 23:13 UTC (permalink / raw) To: Roumen Petrov, cygwin On 3/21/2020 10:26 AM, Roumen Petrov wrote: > Eliot Moss wrote: >> So here's a thing, though I don't understand it: >> >> In addition the build/taskset.exe, there's a build/.libs/taskset.exe. >> If I install the latter in /usr/bin/.libs/taskset.exe, then /usr/bin/taskset >> works. In fact, it seems that the version in .libs is the "real" program >> and /usr/bin/taskset is some kind of trampoline (?) to it? > Libtool wrapper is shell script on Unix/Linux and executable on Microsoft Windows OS. Goal of > "wrapper" is to prepare environment in the way that allows to run real executable without installation. > Project that creates just one executable is not the beast sample but think for a library project and > a bundle of tests (executable). All tests must load library from build tree. > > >> >> In fact, a stripped version of build/.libs/taskset installed in /usr/bin >> works just fine. There must be some kind of build and install convention >> going on that I am not familiar with. (I'm not familiar with a lot of >> these build processes, actually.) > I think that in some cases this executable has to be relinked. Definitely not on Microsoft Windows > OS. So on cygwin it is "final" executable. Thanks - I start to get the picture. What is odd is that 'cygport install' puts the _wrapper_ into /usr/bin rather than the executable, and does not install the exectable. The wrapper just silently fails. Now maybe if I built the package (as if I were the package maintainer) and installed that with cygwin's setup, I would get the right thing - not sure (and not 100% sure how to do that). Cheers - EM ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 23:13 ` Eliot Moss @ 2020-03-22 4:10 ` Eliot Moss 2020-03-22 5:20 ` Eliot Moss 2020-03-24 8:09 ` Mark Geisert 0 siblings, 2 replies; 28+ messages in thread From: Eliot Moss @ 2020-03-22 4:10 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1068 bytes --] Well, I had _thought_ I had done 'cygport install' and run the installed version, but I seem to have been wrong. I seem to have manually over-written the proper (stripped) binary with the wrapper! Anyway, I've got the whole thing working and offer the attached patches for "thoughtful consideration". I have done away with the need to create an empty or fake /usr/local/include/sys/syscall.h and changed the source of the relevant programs to conditional #include <sys/syscall.h> on #indef __CYGWIN__, which sruck me as more legitimate (the file in questions is patched anyway). And I improved configure.ac so that the programs controlled by --enable-schedutils are more independent and can fail individually without failing the build. Part of that was subtituting, as a patch to configure.ac, a check for the sched_getaffinity and sched_setaffinity calls in place of the check for the corresponding syscall. The whole builds and installs. I can provide the packaged up version (I assume that is the 'dist' hierarchy) if that would be helpful. Regards - Eliot [-- Attachment #2: util-linux.cygport --] [-- Type: text/plain, Size: 4179 bytes --] NAME="util-linux" VERSION=2.33.1 RELEASE=1 CATEGORY="Base" SUMMARY="Collection of basic system utilities" HOMEPAGE="https://github.com/karelzak/util-linux/" SRC_URI="https://mirrors.edge.kernel.org/pub/linux/utils/${NAME}/v${PV_MAJ_MIN}/${NAME}-${VERSION}.tar.xz" PATCH_URI=" 2.24.2-libintl.patch 2.25.1-cygwin-include.patch 2.24.2-agetty.patch 2.24.2-libblkid-topology.patch 2.32.1-testsuite.patch 2.33.1-cygwin-cpuset.patch 2.33.1-cygwin-cpuset.patch2 2.33.1-cygwin-ionice.patch 2.33.1-cygwin-taskset.patch " PKG_NAMES="${NAME} libblkid1 libblkid-devel libfdisk1 libfdisk-devel libsmartcols1 libsmartcols-devel libuuid1 libuuid-devel uuidd" util_linux_CONTENTS=" --exclude=*.dll --exclude=uuidd* bin/* sbin/* usr/bin/* usr/share/bash-completion/ usr/share/doc/${NAME} usr/share/locale/*/*/util-linux.mo usr/share/man/man[158]/* " libblkid1_CATEGORY="Libs" libblkid1_SUMMARY="Block device ID library (runtime)" libblkid1_CONTENTS="usr/bin/cygblkid-1.dll" libblkid_devel_CATEGORY="Libs" libblkid_devel_SUMMARY="Block device ID library (development)" libblkid_devel_CONTENTS=" usr/include/blkid/ usr/lib/libblkid.* usr/lib/pkgconfig/blkid.pc usr/share/man/man3/*blkid* " libfdisk1_CATEGORY="Libs" libfdisk1_SUMMARY="Disk partition table manipulation library (runtime)" libfdisk1_CONTENTS="usr/bin/cygfdisk-1.dll" libfdisk_devel_CATEGORY="Libs" libfdisk_devel_SUMMARY="Disk partition table manipulation library (development)" libfdisk_devel_CONTENTS=" usr/include/libfdisk/ usr/lib/libfdisk.* usr/lib/pkgconfig/fdisk.pc " libsmartcols1_CATEGORY="Libs" libsmartcols1_SUMMARY="Tabular data formatting library (runtime)" libsmartcols1_DESCRIPTION="The libsmartcols library is used for smart adaptive formatting of tabular data." libsmartcols1_CONTENTS="usr/bin/cygsmartcols-1.dll" libsmartcols_devel_CATEGORY="Libs" libsmartcols_devel_SUMMARY="Tabular data formatting library (development)" libsmartcols_devel_DESCRIPTION=${libsmartcols1_DESCRIPTION} libsmartcols_devel_CONTENTS=" usr/include/libsmartcols/ usr/lib/libsmartcols.* usr/lib/pkgconfig/smartcols.pc " libuuid1_CATEGORY="Libs" libuuid1_SUMMARY="Universally Unique ID library (runtime)" libuuid1_CONTENTS="usr/bin/cyguuid-1.dll" libuuid_devel_CATEGORY="Libs" libuuid_devel_SUMMARY="Universally Unique ID library (development)" libuuid_devel_CONTENTS=" usr/include/uuid/ usr/lib/libuuid.* usr/lib/pkgconfig/uuid.pc usr/share/man/man3/*uuid* " uuidd_CATEGORY="System" uuidd_SUMMARY="UUID daemon" uuidd_CONTENTS=" usr/sbin/uuidd.exe usr/share/bash-completion/completions/uuidd usr/share/man/man8/uuidd.8* var/lib/libuuid/ var/run/uuidd/ " BUILD_REQUIRES=" bison gettext-devel libcrypt-devel libncurses-devel libreadline-devel zlib-devel " CPPFLAGS+=" -D__USE_LINUX_IOCTL_DEFS" # fsck: e2fsprogs # ipcrm, ipcs: ipc-utils # kill, mount: cygwin # login: login # su: coreutils # last, mesg, mountpoint, utmpdump, wall: sysvinit # others are linux-specific or obsolete CYGCONF_ARGS=" --runstatedir=/var/run --enable-libuuid --enable-libuuid-force-uuidd --enable-libblkid --enable-libfdisk --disable-libmount --disable-mount --disable-losetup --disable-fsck --disable-partx --enable-uuidd --disable-mountpoint --disable-fallocate --disable-unshare --disable-nsenter --disable-setpriv --disable-eject --enable-agetty --enable-cramfs --enable-bfs --disable-fdformat --disable-hwclock --disable-wdctl --disable-switch_root --disable-pivot_root --disable-ipcrm --disable-ipcs --disable-tunelp --disable-kill --disable-last --disable-lslogins --disable-utmpdump --disable-line --disable-mesg --disable-raw --enable-rename --disable-vipw --disable-newgrp --disable-chfn-chsh --disable-login --enable-nologin --disable-sulogin --disable-su --disable-runuser --enable-ul --enable-more --enable-pg --disable-setterm --enable-schedutils --disable-wall --disable-write --disable-use-tty-group --disable-makeinstall-chown --disable-makeinstall-setuid SOLIB_LDFLAGS=-no-undefined " # prevents bogus .so symlinks MAKEOPTS+=" libdir=/usr/lib" KEEPDIRS="/var/lib/libuuid /var/run/uuidd" [-- Attachment #3: 2.33.1-cygwin-cpuset.patch2 --] [-- Type: text/plain, Size: 326 bytes --] --- origsrc/util-linux-2.33.1/lib/cpuset.c 2020-03-21 20:48:54.978830500 -0400 +++ src/util-linux-2.33.1/lib/cpuset.c 2020-03-21 21:21:56.238472500 -0400 @@ -20,7 +20,9 @@ #include <errno.h> #include <string.h> #include <ctype.h> +#ifndef __CYGWIN__ #include <sys/syscall.h> +#endif #include "cpuset.h" #include "c.h" [-- Attachment #4: 2.33.1-cygwin-ionice.patch --] [-- Type: text/plain, Size: 581 bytes --] --- origsrc/util-linux-2.33.1/configure.ac 2020-03-21 20:19:20.952384000 -0400 +++ src/util-linux-2.33.1/configure.ac 2020-03-21 20:42:40.640966200 -0400 @@ -2054,8 +2054,13 @@ ) -UL_ENABLE_ALIAS([ionice], [schedutils]) -UL_BUILD_INIT([ionice]) +AC_ARG_ENABLE([ionice], + AS_HELP_STRING([--disable-ionice], [disable ionice even if schedutils is enabled]), + [], [UL_DEFAULT_ENABLE([ionice], [check])] +) + +UL_BUILD_INIT([ionice], [check]) +UL_REQUIRES_BUILD([ionice], [schedutils]) UL_REQUIRES_SYSCALL_CHECK([ionice], [UL_CHECK_SYSCALL([ioprio_set], [alpha], [442], [-- Attachment #5: 2.33.1-cygwin-taskset.patch --] [-- Type: text/plain, Size: 1036 bytes --] --- origsrc/util-linux-2.33.1/configure.ac 2020-03-21 23:12:49.481503500 -0400 +++ src/util-linux-2.33.1/configure.ac 2020-03-21 23:17:20.565468100 -0400 @@ -2052,6 +2052,7 @@ AS_HELP_STRING([--disable-schedutils], [do not build chrt, ionice, taskset]), [], [UL_DEFAULT_ENABLE([schedutils], [check])] ) +UL_BUILD_INIT([schedutils]) UL_ENABLE_ALIAS([ionice], [schedutils]) @@ -2083,12 +2084,11 @@ AM_CONDITIONAL([BUILD_IONICE], [test "x$build_ionice" = xyes]) -UL_ENABLE_ALIAS([taskset], [schedutils]) -UL_BUILD_INIT([taskset]) +UL_BUILD_INIT([taskset], [check]) +UL_REQUIRES_BUILD([taskset], [schedutils]) UL_REQUIRES_HAVE([taskset], [cpu_set_t], [cpu_set_t type]) -UL_REQUIRES_SYSCALL_CHECK([taskset], - [UL_CHECK_SYSCALL([sched_getaffinity])], - [sched_getaffinity]) +AC_CHECK_FUNCS([sched_getaffinity sched_setaffinity], [have_schedaffinity=yes],[have_schedaffinity=no]) +UL_REQUIRES_HAVE([taskset], [schedaffinity], [sched affinity functions]) AM_CONDITIONAL([BUILD_TASKSET], [test "x$build_taskset" = xyes]) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-22 4:10 ` Eliot Moss @ 2020-03-22 5:20 ` Eliot Moss 2020-03-24 8:09 ` Mark Geisert 1 sibling, 0 replies; 28+ messages in thread From: Eliot Moss @ 2020-03-22 5:20 UTC (permalink / raw) To: cygwin PS - The same patches work fine for a 32-bit build (I just test it). Again, I can supply the package files if desired. Regards - EM ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-22 4:10 ` Eliot Moss 2020-03-22 5:20 ` Eliot Moss @ 2020-03-24 8:09 ` Mark Geisert 2020-03-24 8:16 ` Eliot Moss 1 sibling, 1 reply; 28+ messages in thread From: Mark Geisert @ 2020-03-24 8:09 UTC (permalink / raw) To: moss, cygwin Eliot Moss wrote: > Well, I had _thought_ I had done 'cygport install' and run the installed > version, but I seem to have been wrong. I seem to have manually over-written > the proper (stripped) binary with the wrapper! > > Anyway, I've got the whole thing working and offer the attached patches for > "thoughtful consideration". I have done away with the need to create an empty > or fake /usr/local/include/sys/syscall.h and changed the source of the > relevant programs to conditional #include <sys/syscall.h> on #indef > __CYGWIN__, which sruck me as more legitimate (the file in questions is > patched anyway). And I improved configure.ac so that the programs controlled > by --enable-schedutils are more independent and can fail individually without > failing the build. Part of that was subtituting, as a patch to configure.ac, > a check for the sched_getaffinity and sched_setaffinity calls in place of the > check for the corresponding syscall. The whole builds and installs. I can > provide the packaged up version (I assume that is the 'dist' hierarchy) if > that would be helpful. Thanks very much for working on all this and contributing it. I will build and test as soon as I can. I need to research the packaging steps because I intend to ITA this package. I do also want to take another look at the other programs built as part of --enable-schedutils; they might (or might not) build cleanly but AFAIK there's no support within Cygwin and/or Windows for what they can do on Linux. Thanks again, ..mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-24 8:09 ` Mark Geisert @ 2020-03-24 8:16 ` Eliot Moss 0 siblings, 0 replies; 28+ messages in thread From: Eliot Moss @ 2020-03-24 8:16 UTC (permalink / raw) To: Mark Geisert, cygwin On 3/24/2020 4:09 AM, Mark Geisert wrote: > Eliot Moss wrote: >> Well, I had _thought_ I had done 'cygport install' and run the installed >> version, but I seem to have been wrong. I seem to have manually over-written >> the proper (stripped) binary with the wrapper! >> >> Anyway, I've got the whole thing working and offer the attached patches for >> "thoughtful consideration". I have done away with the need to create an empty >> or fake /usr/local/include/sys/syscall.h and changed the source of the >> relevant programs to conditional #include <sys/syscall.h> on #indef >> __CYGWIN__, which sruck me as more legitimate (the file in questions is >> patched anyway). And I improved configure.ac so that the programs controlled >> by --enable-schedutils are more independent and can fail individually without >> failing the build. Part of that was subtituting, as a patch to configure.ac, >> a check for the sched_getaffinity and sched_setaffinity calls in place of the >> check for the corresponding syscall. The whole builds and installs. I can >> provide the packaged up version (I assume that is the 'dist' hierarchy) if >> that would be helpful. > > Thanks very much for working on all this and contributing it. I will build and test as soon as I > can. I need to research the packaging steps because I intend to ITA this package. I do also want > to take another look at the other programs built as part of --enable-schedutils; they might (or > might not) build cleanly but AFAIK there's no support within Cygwin and/or Windows for what they can > do on Linux. Agreed - glad to help! Eliot ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 8:37 ` Mark Geisert 2020-03-21 10:24 ` Eliot Moss @ 2020-03-22 20:09 ` Yaakov Selkowitz 1 sibling, 0 replies; 28+ messages in thread From: Yaakov Selkowitz @ 2020-03-22 20:09 UTC (permalink / raw) To: cygwin On Sat, 2020-03-21 at 01:37 -0700, Mark Geisert wrote: > Eliot Moss wrote: > > On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote: > > > > > Cygwin doesn't support syscalls. I'd be very wary of any code which is > > > conditional on any #ifdef SYS_*. > > > > Of course. AFAICT taskset does not need the syscall, it just needs the > > library call to work. Asking about the syscall is, I suppose, a kind of Linux > > shorthand to see if something is supported on the particular platform. Mark's > > suggestion of providing a fake definition of that syscall definition is a > > workaround that may disturb the util-linux sources the least. > > What I did here was definitely a hack. I'm not sure it's the best solution. > > I fully concur with Yaakov's warning. There's two levels to syscalls as seen in > programs like taskset. On one level, configure checks whether a particular > syscall exists on the compiling machine because different Linux kernels have > different sets of syscalls. On the second level, the program actually uses a > call named syscall() to call into specific kernel routines. > > On Cygwin, what to do about programs that assume they're running on Linux and so > make use of the Linux syscall feature? We could dummy up a sys/syscall.h but > implementing a full syscall() interface would be a lot of work and do nothing > but slow down programs making heavy use of it; it adds a layer of indirection. I have considered doing just that on multiple occasions, but never got so desperate for it to bother. Keep in mind that kernel APIs often vary from their userspace wrappers (which is one of the two reasons userspace code calls syscall, the other being to access yet-unwrapped calls), meaning such an implementation wouldn't be a simple mapping to existing userspace functions. However, I wouldn't worry so much about performance, the point would be compatibility. > Yaakov, do you have a general strategy for dealing with syscall usage when > you've come across it in all the porting you've done? Cygwin-specific patch? That depends very much on what the code is trying to do (and which syscalls it wants to call!), but using #ifdef SYS_* to guard use of the corresponding userspace function call might be a first. There are definitely some of my packages which I had to patch around syscall assumptions, but I'd have to go find them. -- Yaakov ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-20 5:54 ` Mark Geisert 2020-03-20 10:29 ` Eliot Moss 2020-03-20 13:39 ` Yaakov Selkowitz @ 2020-03-21 4:59 ` Eliot Moss 2020-03-21 8:18 ` Mark Geisert 2 siblings, 1 reply; 28+ messages in thread From: Eliot Moss @ 2020-03-21 4:59 UTC (permalink / raw) To: cygwin On 3/20/2020 1:54 AM, Mark Geisert wrote: > I've reproduced your snags. It/they are due to my having forgotten another tiny update that should > have been part of the 2.33.1-cygwin-cpuset.patch file. If you 'echo "#define SYS_sched_getaffinity > 42" > /usr/local/include/sys/syscall.h' and then back out your other fix attempts, the build using > cygport should work. Dear Mark: Once I did that properly, it built without commenting out that test. Yay! We still need to suppress building ionice, which requires patching configure.ac to provide a separate flag for that. And we still need to #define _GNU_SOURCE before the #include <sched.h> to make the sched_get/setaffinity calls visible. I intend to patch that into taskset.c unless you have a better way of doing it. When I do all this and use 'cygport compile', I get a taskset that appears to work ... as long as I run it in the place where it was built. When I install it, it fails, pretty silently. I have strace outputs from the two cases, but don't know enough about internals to interpret them. It seems that the failure is errno 2, ENOENT. The permissions on the file in the build area and the one in /usr/bin are the same (according to both getfacl and icacls) and they are on the same drive. 'cmp' indicates that the file contents are the same. It's pretty confusing. I've never seen anything like it. It doesn't matter if I give the full path '/usr/bin/taskset' or the shorter 'taskset'. The containing directories have slightly different permissions, but lots of other files in /usr/bin load and run. By running the version in the build directory on a somewhat long-running ls command, and using taskset -p on that running ls from another window, I verified that the affinity mask is indeed getting set. (It was less obvious to me how to tell which cpu it was actually running on.) Your thoughts about not being able to run the installed version? Eliot ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 4:59 ` Eliot Moss @ 2020-03-21 8:18 ` Mark Geisert 2020-03-21 16:41 ` Brian Inglis 0 siblings, 1 reply; 28+ messages in thread From: Mark Geisert @ 2020-03-21 8:18 UTC (permalink / raw) To: moss, cygwin Eliot Moss wrote: > On 3/20/2020 1:54 AM, Mark Geisert wrote: > > > I've reproduced your snags. It/they are due to my having forgotten another > tiny update that should > > have been part of the 2.33.1-cygwin-cpuset.patch file. If you 'echo "#define > SYS_sched_getaffinity > > 42" > /usr/local/include/sys/syscall.h' and then back out your other fix > attempts, the build using > > cygport should work. > > Dear Mark: > > Once I did that properly, it built without commenting out that test. Yay! Great! > We still need to suppress building ionice, which requires patching > configure.ac to provide a separate flag for that. And we still need to > #define _GNU_SOURCE before the #include <sched.h> to make the > sched_get/setaffinity calls visible. I intend to patch that into taskset.c > unless you have a better way of doing it. I still don't get why these are happening for you. You're building util-linux 2.33.1, right? Here's where the ionice build step is rejected by configure on my system (from config.log in the build directory): | #include <sys/syscall.h> | #include <unistd.h> | | int | main () | { | int test = _NR_ioprio_set; | ; | return 0; | } configure:30512: result: no configure:30515: WARNING: Unable to detect syscall ioprio_set. configure:30531: WARNING: ioprio_set syscall not found; not building ionice As far as the missing _GNU_SOURCE #define, that same config.log just a page or two up lists the contents of confdefs.h and therein _GNU_SOURCE is #defined 1. Are you doing a 'cygport clean' between build attempts? > When I do all this and use 'cygport compile', I get a taskset that appears to > work ... as long as I run it in the place where it was built. When I install > it, it fails, pretty silently. I have strace outputs from the two cases, but > don't know enough about internals to interpret them. It seems that the > failure is errno 2, ENOENT. I don't install taskset.exe, I just manually copy the exe into /usr/local/bin. Not that that should matter. The Cygwin-level affinity functions don't set ENOENT, but there might be an underlying Windows affinity function that returns an error that Cygwin maps to ENOENT. > The permissions on the file in the build area and the one in /usr/bin are the > same (according to both getfacl and icacls) and they are on the same drive. > 'cmp' indicates that the file contents are the same. It's pretty confusing. > I've never seen anything like it. It doesn't matter if I give the full path > '/usr/bin/taskset' or the shorter 'taskset'. The containing directories have > slightly different permissions, but lots of other files in /usr/bin load and > run. No idea why it runs in one place but not the other. Other than what might be in your PATH. You might try running 'ldd' on each exe and making sure they're using the same libraries... How could they not? Dunno. Also do 'echo $?' after a run to see what error code the exe is exiting with. > By running the version in the build directory on a somewhat long-running ls > command, and using taskset -p on that running ls from another window, I > verified that the affinity mask is indeed getting set. (It was less obvious > to me how to tell which cpu it was actually running on.) I ended up installing Process Lasso to follow processes among the cpus and to test the Cygwin affinity mask implementation. It has a free trial period. And I wrote a simple test program that just advances from one cpu to the next repeatedly, cpu-bound between steps, so PL can display the changing cpu. ..mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 8:18 ` Mark Geisert @ 2020-03-21 16:41 ` Brian Inglis 2020-03-23 9:31 ` Corinna Vinschen 0 siblings, 1 reply; 28+ messages in thread From: Brian Inglis @ 2020-03-21 16:41 UTC (permalink / raw) To: cygwin On 2020-03-21 02:18, Mark Geisert wrote: > Eliot Moss wrote: >> On 3/20/2020 1:54 AM, Mark Geisert wrote: >>> I've reproduced your snags. It/they are due to my having forgotten >>> another tiny update that should have been part of the >>> 2.33.1-cygwin-cpuset.patch file. If you >>> 'echo "#define SYS_sched_getaffinity 42" > /usr/local/include/sys/syscall.h' >>> and then back out your other fix attempts, the build using cygport should >>> work. >> Once I did that properly, it built without commenting out that test. Yay! > I ended up installing Process Lasso to follow processes among the cpus and to > test the Cygwin affinity mask implementation. It has a free trial period. And > I wrote a simple test program that just advances from one cpu to the next > repeatedly, cpu-bound between steps, so PL can display the changing cpu. Anyone know if this feature support or what feature support will get top P/last used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently assigned CPU showing actual CPUs rather than 0/zero? Anyone know if or where or how this info is available on Windows or a link to it? I've looked at Google and SO results and nothing useful is apparent. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-21 16:41 ` Brian Inglis @ 2020-03-23 9:31 ` Corinna Vinschen 2020-03-23 9:42 ` Mark Geisert 0 siblings, 1 reply; 28+ messages in thread From: Corinna Vinschen @ 2020-03-23 9:31 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1401 bytes --] On Mar 21 10:41, Brian Inglis wrote: > On 2020-03-21 02:18, Mark Geisert wrote: > > Eliot Moss wrote: > >> On 3/20/2020 1:54 AM, Mark Geisert wrote: > >>> I've reproduced your snags. It/they are due to my having forgotten > >>> another tiny update that should have been part of the > >>> 2.33.1-cygwin-cpuset.patch file. If you > >>> 'echo "#define SYS_sched_getaffinity 42" > /usr/local/include/sys/syscall.h' > >>> and then back out your other fix attempts, the build using cygport should > >>> work. > >> Once I did that properly, it built without commenting out that test. Yay! > > > I ended up installing Process Lasso to follow processes among the cpus and to > > test the Cygwin affinity mask implementation. It has a free trial period. And > > I wrote a simple test program that just advances from one cpu to the next > > repeatedly, cpu-bound between steps, so PL can display the changing cpu. > > Anyone know if this feature support or what feature support will get top P/last > used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently > assigned CPU showing actual CPUs rather than 0/zero? > > Anyone know if or where or how this info is available on Windows or a link to > it? I've looked at Google and SO results and nothing useful is apparent. Can't we just fake the calls? Corinna -- Corinna Vinschen Cygwin Maintainer [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-23 9:31 ` Corinna Vinschen @ 2020-03-23 9:42 ` Mark Geisert 2020-03-23 18:48 ` Brian Inglis 0 siblings, 1 reply; 28+ messages in thread From: Mark Geisert @ 2020-03-23 9:42 UTC (permalink / raw) To: cygwin Corinna Vinschen wrote: > On Mar 21 10:41, Brian Inglis wrote: >> On 2020-03-21 02:18, Mark Geisert wrote: >>> Eliot Moss wrote: >>>> On 3/20/2020 1:54 AM, Mark Geisert wrote: >>>>> I've reproduced your snags. It/they are due to my having forgotten >>>>> another tiny update that should have been part of the >>>>> 2.33.1-cygwin-cpuset.patch file. If you >>>>> 'echo "#define SYS_sched_getaffinity 42" > /usr/local/include/sys/syscall.h' >>>>> and then back out your other fix attempts, the build using cygport should >>>>> work. >>>> Once I did that properly, it built without commenting out that test. Yay! >> >>> I ended up installing Process Lasso to follow processes among the cpus and to >>> test the Cygwin affinity mask implementation. It has a free trial period. And >>> I wrote a simple test program that just advances from one cpu to the next >>> repeatedly, cpu-bound between steps, so PL can display the changing cpu. >> >> Anyone know if this feature support or what feature support will get top P/last >> used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently >> assigned CPU showing actual CPUs rather than 0/zero? >> >> Anyone know if or where or how this info is available on Windows or a link to >> it? I've looked at Google and SO results and nothing useful is apparent. > > Can't we just fake the calls? Brian is asking for a way to watch processes globally, as they are scheduled back and forth on the available cpus. I was a bit sloppy in my wording above; what Process Lasso displays is the changing process affinity mask for a process I wrote to do just that. I don't know of a way to ask Windows which cpu a process is currently scheduled onto. ..mark ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Why is taskset still not in util-linux? 2020-03-23 9:42 ` Mark Geisert @ 2020-03-23 18:48 ` Brian Inglis 0 siblings, 0 replies; 28+ messages in thread From: Brian Inglis @ 2020-03-23 18:48 UTC (permalink / raw) To: cygwin On 2020-03-23 03:42, Mark Geisert wrote: > Corinna Vinschen wrote: >> On Mar 21 10:41, Brian Inglis wrote: >>> On 2020-03-21 02:18, Mark Geisert wrote: >>>> Eliot Moss wrote: >>>>> On 3/20/2020 1:54 AM, Mark Geisert wrote: >>>>>> I've reproduced your snags. It/they are due to my having forgotten >>>>>> another tiny update that should have been part of the >>>>>> 2.33.1-cygwin-cpuset.patch file. If you >>>>>> 'echo "#define SYS_sched_getaffinity 42" > /usr/local/include/sys/syscall.h' >>>>>> and then back out your other fix attempts, the build using cygport should >>>>>> work. >>>>> Once I did that properly, it built without commenting out that test. Yay! >>> >>>> I ended up installing Process Lasso to follow processes among the cpus and to >>>> test the Cygwin affinity mask implementation. It has a free trial period. And >>>> I wrote a simple test program that just advances from one cpu to the next >>>> repeatedly, cpu-bound between steps, so PL can display the changing cpu. >>> >>> Anyone know if this feature support or what feature support will get top P/last >>> used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently >>> assigned CPU showing actual CPUs rather than 0/zero? >>> >>> Anyone know if or where or how this info is available on Windows or a link to >>> it? I've looked at Google and SO results and nothing useful is apparent. >> >> Can't we just fake the calls? The results are currently faked to CPU # 0. > Brian is asking for a way to watch processes globally, as they are scheduled > back and forth on the available cpus. I was a bit sloppy in my wording above; > what Process Lasso displays is the changing process affinity mask for a process > I wrote to do just that. I don't know of a way to ask Windows which cpu a > process is currently scheduled onto. You can also get and set affinity in Task Manager, and also ideal CPU info using SysInternals Process Explorer, or PowerShell, which I use to launch Windows ntpd at max realtime priority on CPU `nproc` - 1, as CMD arithmetic was nonexistent or obscure years ago. I could probably redo that with CMD start. Only documented CPU # call I could find was GetCurrentProcessorNumber (-Ex also returns processor group) which tells the current thread where it's executing, not the last or current CPU # assigned or used for other process threads. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2020-03-24 8:16 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-01 21:46 Why is taskset still not in util-linux? Eliot Moss 2020-03-04 13:32 ` Mark Geisert 2020-03-16 23:34 ` Mark Geisert 2020-03-19 10:14 ` Eliot Moss 2020-03-19 10:41 ` Marco Atzeri 2020-03-19 23:29 ` Mark Geisert 2020-03-20 5:54 ` Mark Geisert 2020-03-20 10:29 ` Eliot Moss 2020-03-20 21:42 ` Andrey Repin 2020-03-20 13:39 ` Yaakov Selkowitz 2020-03-21 1:46 ` Eliot Moss 2020-03-21 8:37 ` Mark Geisert 2020-03-21 10:24 ` Eliot Moss 2020-03-21 11:07 ` Eliot Moss 2020-03-21 13:29 ` Marco Atzeri 2020-03-21 14:26 ` Roumen Petrov 2020-03-21 23:13 ` Eliot Moss 2020-03-22 4:10 ` Eliot Moss 2020-03-22 5:20 ` Eliot Moss 2020-03-24 8:09 ` Mark Geisert 2020-03-24 8:16 ` Eliot Moss 2020-03-22 20:09 ` Yaakov Selkowitz 2020-03-21 4:59 ` Eliot Moss 2020-03-21 8:18 ` Mark Geisert 2020-03-21 16:41 ` Brian Inglis 2020-03-23 9:31 ` Corinna Vinschen 2020-03-23 9:42 ` Mark Geisert 2020-03-23 18:48 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).