Why is taskset still not in util-linux?

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Why is taskset still not in util-linux?

Eliot Moss

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

Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Mark Geisert
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

Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Mark Geisert
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Cygwin list mailing list
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


--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Mark Geisert
In reply to this post by Eliot Moss
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Mark Geisert
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Eliot Moss
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Yaakov Selkowitz
In reply to this post by Mark Geisert
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


--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Andrey Repin
In reply to this post by Eliot Moss
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...
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Eliot Moss
In reply to this post by Yaakov Selkowitz
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Eliot Moss
In reply to this post by Mark Geisert
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Mark Geisert
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Mark Geisert
In reply to this post by Eliot Moss
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Eliot Moss
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

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.
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Cygwin list mailing list
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


--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Roumen Petrov
In reply to this post by Eliot Moss
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Brian Inglis
In reply to this post by Mark Geisert
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.
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
Reply | Threaded
Open this post in threaded view
|

Re: Why is taskset still not in util-linux?

Eliot Moss
In reply to this post by Roumen Petrov
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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
12