On Sun, Feb 16, 2014 at 6:50 AM, Marco Ippolito <maroloc...@gmail.com> wrote:
> On 11 Feb 2014, at 04:09, Joel Rees <joel.r...@gmail.com> wrote:
>
>> On Tue, Feb 11, 2014 at 9:03 AM, Chris Davies <ch...@roaima.co.uk> wrote:
>>> Marco Ippolito <maroloc...@gmail.com> wrote:
>>>> How can I `echo', in `bash', the core # the current script is running on?
>>>
>>> This will probably do it for you
>>> awk '{print $39}' /proc/$$/stat
>>>
>>> See proc(5) for details, including the 39. Please also note that unless
>>> you've set the task affinity (see taskset(1) for details) the process
>>> can - and will - be reassigned different cores during its lifetime.
>>
>> Heh. What odds do you give it that the processor will be running on a
>> different core by the time his script has IDed the core? Or maybe even
>> cycled back again?
>>
>> But, I guess if the OP's purpose is just to prove that scripts are not
>> confined to a single core, I guess it doesn't matter. (I can't say
>> that I can think of any other reason for the question, now that I
>> think of it. Hmm)
>>
>> --
>> Joel Rees
>>
>> Be careful where you see conspiracy.
>> Look first in your own heart.
>
> Appreciated the discussion, thanks. Yes, I was trying to verify some
> behaviour, a bit like the following Bash one-liner, but in another context,
> and `taskset' helped me more than looking at `printf' as an aftermath:
>
> bash4$ f=/tmp/delme; printf '%s\n' '#include <stdio.h>' '#include <sched.h>'
> 'int main(int argc, const char* argv[]) { printf("job: %s; sched_getcpu():
> %d\n", argv[1], sched_getcpu()); return 0; }' | gcc -x c -o "$f" - &&
> parallel -j 0 "$f" {#} -- {1..9}
>
> job: 1; sched_getcpu(): 0
> job: 2; sched_getcpu(): 1
> job: 3; sched_getcpu(): 1
> job: 4; sched_getcpu(): 1
> job: 5; sched_getcpu(): 1
> job: 6; sched_getcpu(): 1
> job: 7; sched_getcpu(): 1
> job: 8; sched_getcpu(): 0
> job: 9; sched_getcpu(): 1
>
> Printing job IDs, "cpu" numbers, etc.
>
> In the end I just rewrote my "script" in C.
I assume you understand the principle, but for the benefit of others
who might be reading along --
By principle, if Linux's scheduler is working well, by the time you
report back to your user-land process, the process may have switched
CPUs. And by the time it prints the list to the screen, it will almost
certainly have yielded the cpu and been re-assigned. Still, C should
yield more interesting results because scripts interact with the login
shell (and X11?) significantly more, and in ways that become
predictable -- something like ruts in a dirt road or tracks in snow,
but not as self-reinforcing.
If you only need to demonstrate that the kernel is distributing your
process across the CPUs, doing something like your script in C may be
good enough.
A few years ago, the Linux kernel was so monolithic that you could be
confident that, having checked which CPU you were on, you'd be on that
CPU until you left the kernel. That is no longer the case, which is
progress.
If you need to control or be sensitive to CPU selection, you need
real-time access libraries and you probably need a slightly patched
and re-compiled kernel, at minimum, if not a full-on real-time version
of Linux or a true real-time OS. See:
man -k semaphore
man -k mutex
man -k spinlock
etc., although the man pages assume a lot of understanding of the
theory and the code itself, and do not fully explain the theory and
how the theory plays out in the code.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caar43ipdbxlacsjfrs6d7tsodjx45a2cl_6oyctx2oajp6i...@mail.gmail.com
