|
From: Pim N. <pn...@ai...> - 2006-10-18 11:59:41
|
Hi,
First of all. Valgrind works great! However I'm having some trouble with
thread scheduling.
I noticed that Valgrinds scheduler yields the processor to another
thread after excecuting N basic blocks. Does someone know why Valgrinds
scheduler uses slices instead of just relying on the scheduling of the
threads?
I try to run Valgrind 3.2.1 on an embedded system (ppc32) where the
application sets a fifo scheduling policy for the threads.
Since I need to keep fifo scheduling I need to disable this slice
system. Is it save to comment out the following lines in the scheduler?
while(!VG_(is_exiting)(tid)) {
if (VG_(dispatch_ctr) == 1) {
VG_(set_sleeping)(tid, VgTs_Yielding); // <-- comment out
/* nothing */
VG_(set_running)(tid); // <-- comment out
...
This seemed to me the least aggresive change. Running this seems to be
fine, but I figured there would be a reason for this slice business and
maybe I screw it up.
--
Do you know about the dangers of DRM? Find out at
http://www.defectivebydesign.org/what_is_drm
--
This message has been scanned for viruses and is believed to be clean
|
|
From: Tom H. <to...@co...> - 2006-10-18 12:21:41
|
In message <453...@ai...>
Pim Nijdam <pn...@ai...> wrote:
> I noticed that Valgrinds scheduler yields the processor to another
> thread after excecuting N basic blocks. Does someone know why Valgrinds
> scheduler uses slices instead of just relying on the scheduling of the
> threads?
Because valgrind deliberately only allows one thread to run at a
time (because none of the translation machinery, or things like
memcheck, is threadsafe) so it has to switch threads manually.
All threads except the running one will be blocked waiting for
valgrinds master lock, which the set_sleeping call will release
allowing the kernel scheduler to give control to another thread.
> I try to run Valgrind 3.2.1 on an embedded system (ppc32) where the
> application sets a fifo scheduling policy for the threads.
> Since I need to keep fifo scheduling I need to disable this slice
> system. Is it save to comment out the following lines in the scheduler?
>
> while(!VG_(is_exiting)(tid)) {
> if (VG_(dispatch_ctr) == 1) {
> VG_(set_sleeping)(tid, VgTs_Yielding); // <-- comment out
> /* nothing */
> VG_(set_running)(tid); // <-- comment out
> ...
>
> This seemed to me the least aggresive change. Running this seems to be
> fine, but I figured there would be a reason for this slice business and
> maybe I screw it up.
With your change control will only ever move to a new thread when a
system call blocks, so a thread which makes no blocking system calls
will run forever.
Note that it is still the kernel scheduler which decide which thread
to run next when set_sleeping is called, so the thread should still
run in FIFO order if that is what you have told the kernel to do - all
we do is control when the switch occurs.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Pim N. <pn...@ai...> - 2006-10-18 14:44:17
|
Thanks for your reply. Tom Hughes wrote: > Because valgrind deliberately only allows one thread to run at a > time (because none of the translation machinery, or things like > memcheck, is threadsafe) so it has to switch threads manually. > > All threads except the running one will be blocked waiting for > valgrinds master lock, which the set_sleeping call will release > allowing the kernel scheduler to give control to another thread. Ah, that's the thing I forgot: all other threads are blocked and won't be scheduled by the kernel. > Note that it is still the kernel scheduler which decide which thread > to run next when set_sleeping is called, so the thread should still > run in FIFO order if that is what you have told the kernel to do - all > we do is control when the switch occurs. That's the point. When a thread is 'sleeping' (blocked for valgrind's run semafor) another thread will be scheduled. But maybe there was no reason (higher priority thread) to switch to another thead. I'm concerned that instead of running one thread untill say a higher priority thread is scheduled. Two threads will run interleaved (one with possibly a lower priority). Is my concern grounded? Pim Nijdam -- This message has been scanned for viruses and is believed to be clean |
|
From: Tom H. <to...@co...> - 2006-10-18 15:14:30
|
In message <453...@ai...>
Pim Nijdam <pn...@ai...> wrote:
>> Note that it is still the kernel scheduler which decide which thread
>> to run next when set_sleeping is called, so the thread should still
>> run in FIFO order if that is what you have told the kernel to do - all
>> we do is control when the switch occurs.
>
> That's the point. When a thread is 'sleeping' (blocked for valgrind's
> run semafor) another thread will be scheduled. But maybe there was no
> reason (higher priority thread) to switch to another thead. I'm
> concerned that instead of running one thread untill say a higher
> priority thread is scheduled. Two threads will run interleaved (one with
> possibly a lower priority). Is my concern grounded?
Well set_sleeping will write to the pipe that all the other threads
that are ready to run (ie not blocked in a system call made by the
client) are trying to read from.
How the kernel chooses which of threads which are trying to read from
the pipe to wake up is up to it - but I assume it would respect the
currently active scheduler algorithm?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Pim N. <pn...@ai...> - 2006-10-19 10:00:52
|
Julian Seward wrote: >>>priority thread is scheduled. Two threads will run interleaved (one with >>>possibly a lower priority). Is my concern grounded? >> >>Well set_sleeping will write to the pipe that all the other threads >>that are ready to run (ie not blocked in a system call made by the >>client) are trying to read from. >> >>How the kernel chooses which of threads which are trying to read from >>the pipe to wake up is up to it - but I assume it would respect the >>currently active scheduler algorithm? Yes you're right Tom. My fallacy was the folowing: I reasoned that as soon as the current running thread would write to the pipe another thread would be scheduled. But of course the scheduler may choose to continue running the current running thread, enabling it to reclaim Valgrinds lock. > I agree with Tom. Valgrind only really provides a lock which stops > more than one thread running at once. It doesn't mess with scheduling > or priorities in any other way. So unless the kernel is doing something > strange, your priorities should be observed. Can you create a small > test case that shows the problem? I tried, but it showed me I was wrong. Well I can happily use Valgrind without having to worry about this! Thanks to both of you for your quick replies. Pim Nijdam -- This message has been scanned for viruses and is believed to be clean |
|
From: Nicholas N. <nj...@cs...> - 2006-10-19 10:16:46
|
On Thu, 19 Oct 2006, Pim Nijdam wrote: > Yes you're right Tom. My fallacy was the folowing: I reasoned that as > soon as the current running thread would write to the pipe another > thread would be scheduled. But of course the scheduler may choose to > continue running the current running thread, enabling it to reclaim > Valgrinds lock. Yes, that's how it works with single-threaded programs :) Nick> |
|
From: Julian S. <js...@ac...> - 2006-10-18 15:23:16
|
> > priority thread is scheduled. Two threads will run interleaved (one with > > possibly a lower priority). Is my concern grounded? > > Well set_sleeping will write to the pipe that all the other threads > that are ready to run (ie not blocked in a system call made by the > client) are trying to read from. > > How the kernel chooses which of threads which are trying to read from > the pipe to wake up is up to it - but I assume it would respect the > currently active scheduler algorithm? I agree with Tom. Valgrind only really provides a lock which stops more than one thread running at once. It doesn't mess with scheduling or priorities in any other way. So unless the kernel is doing something strange, your priorities should be observed. Can you create a small test case that shows the problem? J |