scheduling frequency for threaded applications ?
Hello,
I'm developping a network benchmark application ("packet blaster").
The current version uses many processes, to send and receive packets,
and collate statistics.
when I look at top(1), I see most of the time taken is in the "system"
category. I assume this is due to the many context switches between the
collaborating processes.
If I want to get rid of this system overhead, one solution is to use
threads (all sharing the same address space, thus no more context
switching).
My question is : how otfen are the threads rescheduled ?
(all threads are mainly always blocked until an event arrives, either a
timeout with select() or a packet with recevmsg())
I've had a quick look a TFM, but I don't see anything applicable
(pthread_setschedparam(3) for example does not speak of scheduling
frequency)
--
Thierry Herbelot
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: scheduling frequency for threaded applications ?
Alfred Perlstein wrote:
* Thierry Herbelot [EMAIL PROTECTED] [010319 11:43] wrote:
Hello,
I'm developping a network benchmark application ("packet blaster").
The current version uses many processes, to send and receive packets,
and collate statistics.
when I look at top(1), I see most of the time taken is in the "system"
category. I assume this is due to the many context switches between the
collaborating processes.
You're incorrect. System means just about any time spent inside the
kernel (except interrupts), so basically syscalls count towards this
meaning that your application is driving the kernel pretty hard.
This is easy for a team of processes, but nearly impossible with
a thread based approach.
could you please elaborate ? (indeed, if you could also shed some light
on the first question : how frequently are threads rescheduled ?)
You don't want to use threads.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
PS : the TI-RPC commit was a nice one !
--
Thierry Herbelot
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: scheduling frequency for threaded applications ?
* Thierry Herbelot [EMAIL PROTECTED] [010319 11:59] wrote:
Alfred Perlstein wrote:
* Thierry Herbelot [EMAIL PROTECTED] [010319 11:43] wrote:
Hello,
I'm developping a network benchmark application ("packet blaster").
The current version uses many processes, to send and receive packets,
and collate statistics.
when I look at top(1), I see most of the time taken is in the "system"
category. I assume this is due to the many context switches between the
collaborating processes.
You're incorrect. System means just about any time spent inside the
kernel (except interrupts), so basically syscalls count towards this
meaning that your application is driving the kernel pretty hard.
This is easy for a team of processes, but nearly impossible with
a thread based approach.
could you please elaborate ? (indeed, if you could also shed some light
on the first question : how frequently are threads rescheduled ?)
I really have no idea how frequently threads are rescheduled.
the point is this:
In FreeBSD a threaded application has a single process context, meaning
that the kernel schedules all threads as a single entity. In effect
you limit the parallelness(?) by using threads.
Now if you want kernel threads, then use the linux-threads port, however
you're back to normal process scheduling because afaik linux-threads
(at least when run on FreeBSD) are implemented with processes.
I don't think you understand that the overhead you're seeing is
most likely _not_ because of any scheduler issue, but more likely
because you're asking the kernel to do a signifigant amount of
work for you.
This is about as far as I'm going to go on the issue, basically once
you make your "write()" syscall, you enter into 'system' time because
you're having the kernel do work for you.
The getrusage() manpage might be a good place to look for more
answers.
PS : the TI-RPC commit was a nice one !
There's still a few kinks to work out, hope to have it fixed within
the next couple of days.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
