On Friday, December 16, 2016 12:10:01 PM Adrian Chadd wrote:
> On 16 December 2016 at 11:45, Luigi Rizzo wrote:
> > On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
> >> On 16 Dec 2016, at 03:10, Alan Somers wrote:
> >> >
> >> > What about
On 16 December 2016 at 11:45, Luigi Rizzo wrote:
> On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
>> On 16 Dec 2016, at 03:10, Alan Somers wrote:
>> >
>> > What about pthread_setaffinity(3) and friends? You can use it to pin
>> > a
On Fri, Dec 16, 2016 at 09:29:15AM +, David Chisnall wrote:
> On 16 Dec 2016, at 03:10, Alan Somers wrote:
> >
> > What about pthread_setaffinity(3) and friends? You can use it to pin
> > a thread to a single CPU, and know that it will never migrate.
>
> This is not a
On Fri, Dec 16, 2016 at 03:17:19AM +0100, Luigi Rizzo wrote:
> TL;DR; is there any way a userspace thread in FreeBSD can tell
> on which CPU it is (was) running ? I know the thread can migrate
> at any time but as long as the event is rare I can live with
> the occasionally wrong information.
>
On Thu, Dec 15, 2016 at 7:17 PM, Luigi Rizzo wrote:
> TL;DR; is there any way a userspace thread in FreeBSD can tell
> on which CPU it is (was) running ? I know the thread can migrate
> at any time but as long as the event is rare I can live with
> the occasionally wrong
TL;DR; is there any way a userspace thread in FreeBSD can tell
on which CPU it is (was) running ? I know the thread can migrate
at any time but as long as the event is rare I can live with
the occasionally wrong information.
Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3),
but the