2012/2/24, Eugene Grosbein egrosb...@rdtc.ru:
28.01.2012 20:22, Attilio Rao пишет:
2012/1/28 Ryan Stone ryst...@gmail.com:
On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao atti...@freebsd.org
wrote:
I think what you found out is very sensitive.
However, the patch is not correct as you cannot
24.02.2012 18:45, Attilio Rao пишет:
I have the pathological test-case for it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=165444
A fix has been committed as r230984, it should apply to STABLE_9/8
too, can you try it?
Attilio
I will try but I already run my patch for netisr, so it
2012/2/24, Eugene Grosbein eu...@grosbein.pp.ru:
24.02.2012 18:45, Attilio Rao пишет:
I have the pathological test-case for it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=165444
A fix has been committed as r230984, it should apply to STABLE_9/8
too, can you try it?
Attilio
I will try
28.01.2012 20:22, Attilio Rao пишет:
2012/1/28 Ryan Stone ryst...@gmail.com:
On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao atti...@freebsd.org wrote:
I think what you found out is very sensitive.
However, the patch is not correct as you cannot call
cpuset_setthread() with thread_lock held.
24.02.2012 19:05, Attilio Rao пишет:
2012/2/24, Eugene Grosbein eu...@grosbein.pp.ru:
24.02.2012 18:45, Attilio Rao пишет:
I have the pathological test-case for it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=165444
A fix has been committed as r230984, it should apply to STABLE_9/8
too,
On Sat, Jan 28, 2012 at 8:22 AM, Attilio Rao atti...@freebsd.org wrote:
Do you have a pathological test-case for it? Are you going to test the patch?
Thanks,
Attilio
I tested the patch last night. Previously I was able to see a
softclock thread preempted for over 1ms on machine where 4/8
On Sat, Jan 28, 2012 at 02:39:17PM +0100, Attilio Rao wrote:
2012/1/28 Attilio Rao atti...@freebsd.org:
2012/1/28 Ryan Stone ryst...@gmail.com:
On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao atti...@freebsd.org wrote:
I think what you found out is very sensitive.
However, the patch is not
2012/1/28 Ryan Stone ryst...@gmail.com:
On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao atti...@freebsd.org wrote:
I think what you found out is very sensitive.
However, the patch is not correct as you cannot call
cpuset_setthread() with thread_lock held.
Whoops! I actually discovered that
2012/1/28 Attilio Rao atti...@freebsd.org:
2012/1/28 Ryan Stone ryst...@gmail.com:
On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao atti...@freebsd.org wrote:
I think what you found out is very sensitive.
However, the patch is not correct as you cannot call
cpuset_setthread() with thread_lock
). Inheriting affinity is arguably correct for
userland threads (at the very least, an explicit design decision to
implement inheritance was clearly implemented). However for kernel
threads, this behaviour leads to bizarre results that clearly weren't
intended. For example, I added a printf
thread spawned in
that kernel process). Inheriting affinity is arguably correct for
userland threads (at the very least, an explicit design decision to
implement inheritance was clearly implemented). However for kernel
threads, this behaviour leads to bizarre results that clearly weren't
On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao atti...@freebsd.org wrote:
I think what you found out is very sensitive.
However, the patch is not correct as you cannot call
cpuset_setthread() with thread_lock held.
Whoops! I actually discovered that for myself and had already fixed
it, but
On Monday 15 February 2010 6:21:40 am Shrikanth Kamath wrote:
Can ktrace trace another kernel thread which has roughly the semantics as
below, right now it
does not hit any of the designated interesting points that ktrace is built
for, but what if I could define those,
will ktrace still allow
Can ktrace trace another kernel thread which has roughly the semantics as
below, right now it
does not hit any of the designated interesting points that ktrace is built
for, but what if I could define those,
will ktrace still allow tracing another kernel thread?
thread(client_info)
{
...
- Original Message
From: Shrikanth Kamath shrikant...@gmail.com
To: freebsd-hackers@freebsd.org
Sent: Mon, February 15, 2010 8:21:40 AM
Subject: Ktrace'ing kernel threads
Can ktrace trace another kernel thread which has roughly the semantics as
below, right now it
does not hit
In the last episode (Feb 22), Dmitry Agaphonov said:
I'm forced to implement kernel threads in application not via
LinuxThreads library (because it doesn't compile on FreeBSD 4.10 with
gcc-3.4.4, too much errors while processing /usr/src code), but using
rfork_thread(3).
Why not build
Hello all,
I'm forced to implement kernel threads in application not via LinuxThreads
library (because it doesn't compile on FreeBSD 4.10 with gcc-3.4.4, too
much errors while processing /usr/src code), but using rfork_thread(3).
And the main question I currently stuck on is which libc functions
Sridhar,
I heard that even Interrupts run under kernel threads context
See ithread(9).
How can a kernel thread yield CPU when it detects it is idle?
kthread_suspend(), or yield(). See kthread(9), mi_switch(9).
Let me also answer your questions(s) at another level: I have found
Some questions on kernel threads under BSD :
Is there a way to tie a kernel thread to a specific CPU? Is it also
possible to move a kernel thread from one CPU to another ?
Is there a way to make a kernel thread non-Pre-emptible ? Is yes how do
we do it?
I heard that even Interrupts run under
this for a while -- clustering the
kernel threads into a smaller number of kernel processes or a single
kernel process. This is the approach Darwin takes as well, FWIW -- they
have a kernel_task in which all the various kernel threads hang out, which
avoids the overhead of full processes, as well
Actually, i was fiddling around with the kernel splash screen code in
order to make it 'animated'... such as the BeOS splash screen.
I first used the syscons screen timer to make the splash screen change
but programming this way is quite ugly, and thought about creating a new
thread
within the
On Wed, 28 Jan 2004, Unix Shepherd wrote:
Actually, i was fiddling around with the kernel splash screen code in
order to make it 'animated'... such as the BeOS splash screen.
I first used the syscons screen timer to make the splash screen change
but programming this way is quite ugly, and
Hi everybody.
I'm trying to use the kthread library under 5.2-RELEASE but can't
compile my program
(which actually only tries to create a thread).
I've read that there is now KSE to create kernel threads, but i am
wondering if
it could be used within the kernel code.
Regards
On Tue, 27 Jan 2004, Renaud Molla Wanadoo wrote:
I'm trying to use the kthread library under 5.2-RELEASE but can't
compile my program (which actually only tries to create a thread).
I've read that there is now KSE to create kernel threads, but i am
wondering if it could be used within
Hi,
I am writing a kernel module in which I have created a kernel thread with
kthread_create. For debugging I have added a couple of printf's in the
thread-routine. Running the module on a single-proc system works fine, but
when running it on one of my SMP machines the console freezes after a
Hello,
does FreeBSD currently have something similar to linux's kernel_thread() ?
Or is it what KSE intends to implement ? Can I somehow run independent
kernel thread, which will, for instance, check some flag that I set inside
interrupt handler and do some job that can't be done in the
* Eugene L. Vorokov [EMAIL PROTECTED] [011025 03:03] wrote:
Hello,
does FreeBSD currently have something similar to linux's kernel_thread() ?
Or is it what KSE intends to implement ? Can I somehow run independent
kernel thread, which will, for instance, check some flag that I set inside
On 25-Oct-01 Eugene L. Vorokov wrote:
Hello,
does FreeBSD currently have something similar to linux's kernel_thread() ?
Or is it what KSE intends to implement ? Can I somehow run independent
kernel thread, which will, for instance, check some flag that I set inside
interrupt handler and
On Thu, 25 Oct 2001, Eugene L. Vorokov wrote:
Hello,
does FreeBSD currently have something similar to linux's kernel_thread() ?
Or is it what KSE intends to implement ? Can I somehow run independent
kernel thread, which will, for instance, check some flag that I set inside
interrupt
Are threads on FreeBSD 4.x implemented at the
kernel level?
If so, since when (I remember 2.x used MIT-threads,
so I'm guessing at least since 3.x)?
How can I see for myself that threads are really
implemented at the kernel level? I looked around
in /usr/src/sys/kern, but couldn't find
implemented at the kernel level? I looked around
in /usr/src/sys/kern, but couldn't find anything
relating to threads there.
They aren't really implemented at the kernel level yet, but something like
kernel threads will be in 5.x when it comes out. If you really need kernel
threads in FreeBSD
On 04-Jan-01 Marc Tardif wrote:
Are threads on FreeBSD 4.x implemented at the
kernel level?
No, they probably will not be until 6.0.
If so, since when (I remember 2.x used MIT-threads,
so I'm guessing at least since 3.x)?
How can I see for myself that threads are really
implemented at
Hi
Is it possible to implement threads in FreeBSD 4.0 kernel using the rfork
system call? If yes, could you give an example?
I tried to get the following piece of code to work without success.
#include unistd.h
main()
{
if (rfork( RFPROC | RFNOWAIT | RFMEM | RFSIGSHARE ) 0)
{
* Satyajeet Seth [EMAIL PROTECTED] [001212 02:21] wrote:
Hi
Is it possible to implement threads in FreeBSD 4.0 kernel using the rfork
system call? If yes, could you give an example?
I tried to get the following piece of code to work without success.
#include unistd.h
main()
{
Hi,
FreeBSD provides the pthread package (available through the
use of the option -pthread to gcc). Does this package use user-level
threads or does it use kernel threads ? I believe the kernel supports
multiple threads in the same address space using the rfork() system
call.
- Mohit
* Mohit Aron [EMAIL PROTECTED] [001129 01:32] wrote:
Hi,
FreeBSD provides the pthread package (available through the
use of the option -pthread to gcc). Does this package use user-level
threads or does it use kernel threads ? I believe the kernel supports
multiple threads in the same
On Wed, 29 Nov 2000, Mohit Aron wrote:
-Hi,
- FreeBSD provides the pthread package (available through the
-use of the option -pthread to gcc). Does this package use user-level
-threads or does it use kernel threads ? I believe the kernel supports
-multiple threads in the same address space
On Mon, 17 Jul 2000, Zhihui Zhang wrote:
I am writing a KLD that gives me kernel fault each time I run 'ps' command
after 'make unload'. The KLD has a system call to create several kernel
threads by calling kthread_create(). During unload, I set flags to each
threads so
I am writing a KLD that gives me kernel fault each time I run 'ps' command
after 'make unload'. The KLD has a system call to create several kernel
threads by calling kthread_create(). During unload, I set flags to each
threads so that they will call exit1() upon wakeup (sleep on a timeout
(I CC:'d to -hackers, perhaps someone can enlighten us wrt. the
availability of kernel threads..)
On Fri, 26 May 2000, Koster, K.J. wrote:
Has anyone had a look at this? Reports are that it's a big
improvement over the BDown stuff. Anyone had a play yet?
1.3 is a big improvement
I have created several kernel threads that can die after being idle for a
while. I did this by copying the kthread_create() funtion from CURRENT
over to FreeBSD 3.3-Release. Is there a way to remove the zombie threads
after they die or prevent them from creating? Any potential problems in
trying
Christopher Sedore wrote:
On Thu, 6 Jan 2000, Arjan de Vet wrote:
Jordan K. Hubbard wrote:
This is very interesting data and I was just wondering about the
actual state of functionality in our AIO code just the other day,
oddly enough. Does anyone have a PR# for the mentioned patches?
On Mon, Jan 10, 2000 at 10:48:29PM +0100, Arjan de Vet wrote:
Christopher Sedore wrote:
On Thu, 6 Jan 2000, Arjan de Vet wrote:
Jordan K. Hubbard wrote:
This is very interesting data and I was just wondering about the
actual state of functionality in our AIO code just the other
On Thu, 6 Jan 2000, Arjan de Vet wrote:
Jordan K. Hubbard wrote:
This is very interesting data and I was just wondering about the
actual state of functionality in our AIO code just the other day,
oddly enough. Does anyone have a PR# for the mentioned patches?
kern/12053
A Dec 16
With respect to AIO... we run a data server which multiplexes
on the select() function, and uses AIO to do all it's I/O. This
has been a very stable system.
system : 4.0-19990827-SNAP
start time : 1999/12/24 11:14:44
up time (days hh:mm:ss): 12 13:32:53
This is very interesting data and I was just wondering about the
actual state of functionality in our AIO code just the other day,
oddly enough. Does anyone have a PR# for the mentioned patches?
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the
processes sharing the same virtual memory space,
and are referred to as kernel threads. For compute bound activities you
want kernel threads to spread the computation over multiple processors.
For I/O bound activities you want user level threads so you can minimize
the context switch overhead.
As
In article [EMAIL PROTECTED] you
write:
The best fix I've thought of thus far (other than async I/O, which I
understand isn't ready for prime time) would be to have a number of kernel
Speaking of AIO, which I would really like to use if possible, how
actively maintained is it? The copyright
le(1); ? I thougt that this while statement
would get executed forever (until I press ^C).
On Linux they are processes sharing the same virtual memory space,
and are referred to as kernel threads. For compute bound activities you
want kernel threads to spread the computation over multiple
Hello,
From: Kip Macy [EMAIL PROTECTED]
To: Richard Seaman, Jr. [EMAIL PROTECTED]
They may be preemptive, but I saw a lot of instances with Lyris where one
thread could easily monopolize processor time at the expense of all
others and I had to add sleeps in at places.
Does this mean I've
On Tue, Dec 28, 1999 at 10:44:19AM +0100, Steffen Merkel wrote:
Sorry, but I'm learning C for only some weeks now. Why does the main
thread complete if I insert a while(1); ? I thougt that this while statement
would get executed forever (until I press ^C).
You're right, of course. My brain
On Tue, Dec 28, 1999 at 08:30:08AM -0600, Richard Seaman, Jr. wrote:
On Tue, Dec 28, 1999 at 10:44:19AM +0100, Steffen Merkel wrote:
Sorry, but I'm learning C for only some weeks now. Why does the main
thread complete if I insert a while(1); ? I thougt that this while statement
would get
They may be preemptive, but I saw a lot of instances with Lyris where one
thread could easily monopolize processor time at the expense of all
others and I had to add sleeps in at places.
Does this mean I've got to add sleeps in my threads to let other threads get
cpu time? Is there no
On Tue, 28 Dec 1999, Richard Seaman, Jr. wrote:
On Tue, Dec 28, 1999 at 08:30:08AM -0600, Richard Seaman, Jr. wrote:
On Tue, Dec 28, 1999 at 10:44:19AM +0100, Steffen Merkel wrote:
Sorry, but I'm learning C for only some weeks now. Why does the main
thread complete if I insert a
How can I then tell FreeBSD that my threads shall be kernel threads?
Steffen
The only way I know of to do that is to use LinuxThreads which, because of
my negative experience on Linux with threads, I have not tried. Try the
archives.
-Kip
How can I then tell FreeBSD that my threads shall be kernel threads?
Steffen
The only way I know of to do that is to use LinuxThreads which, because of
my negative experience on Linux with threads, I have not tried. Try the
archives.
Kip, if you have the time and energy, it would
mory space,
and are referred to as kernel threads. For compute bound activities you
want kernel threads to spread the computation over multiple processors.
For I/O bound activities you want user level threads so you can minimize
the context switch overhead. I am sure Julian and the others have
somethin
st a while() the main thread completes before the
second thread gets its time slice. As noted in a previous message,
pthread_join() is intended for this kind of synchronization.
On Linux they are processes sharing the same virtual memory space,
and are referred to as kernel threads. For com
I have not played with it for several months, so this may no longer be the
case.
-Kip
Is this recently, or a while ago? FreeBSD user threads used to use
SIGVTALRM for its pre-emption signal. This didn't count time in
syscalls. So, if you had a syscall (eg
On Mon, 27 Dec 1999, Richard Seaman, Jr. wrote:
On Mon, Dec 27, 1999 at 10:30:54AM -0800, Kip Macy wrote:
They may be preemptive, but I saw a lot of instances with Lyris where one
thread could easily monopolize processor time at the expense of all
others and I had to add sleeps in at
I'd like to bring a kernel thread implementation, ported from NetBDS
by the newconfig project, into the kernel. Who would like to review
things before they go into the tree? I can see many benefits for
having this in the tree, but very little downside. This should allow
people to more easily
?
:
:julian
I think we desparately need a kernel threads implementation. *Any*
implementation, so we can start messing around with it! Even if it isn't
the one we eventually choose.
Once we have something we can add interrupt-thread support to it and
then move some of the more
On 28-Jun-99 Matthew Dillon wrote:
I think we desparately need a kernel threads implementation. *Any*
implementation, so we can start messing around with it! Even if it isn't
the one we eventually choose.
I don't suppose someone could post an explanation of how kernel
In message [EMAIL PROTECTED] Julian
Elischer writes:
: now this is threads within the kernel, and not kernel support for user
: threads right?
Yes. That's right.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
In message [EMAIL PROTECTED] "Daniel J. O'Connor" writes:
: I don't suppose someone could post an explanation of how kernel threads work
: could they? :)
Looks like it just does a fork like thing so it can do context
switches...
Warner
To Unsubscribe: send mail to [EMAIL
On Mon, 28 Jun 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] "Daniel J. O'Connor" writes:
: I don't suppose someone could post an explanation of how kernel threads work
: could they? :)
Looks like it just does a fork like thing so it can do context
switches...
Warner Losh wrote:
In message [EMAIL PROTECTED] "Daniel J. O'Connor" writ
es:
: I don't suppose someone could post an explanation of how kernel threads wor
k
: could they? :)
Looks like it just does a fork like thing so it can do context
switches...
Warner
When I l
In message [EMAIL PROTECTED] "Daniel
J. O'Connor" writes:
: I don't suppose someone could post an explanation of how kernel threads work
: could they? :)
In a nutshell, it appears to basically do an rfork. It then becomes
like any other process that is interrupted in the kernel.
I'd like to bring a kernel thread implementation, ported from NetBDS
by the newconfig project, into the kernel. Who would like to review
things before they go into the tree? I can see many benefits for
having this in the tree, but very little downside. This should allow
people to more easily
please yes..
eventually we'll be using it to fire off a thread for every interrupt
source if we go the BSDI way. (as dicussed with various people at USENIX)
I was actually thinking about this today...
now this is threads within the kernel, and not kernel support for user
threads right?
?
:
:julian
I think we desparately need a kernel threads implementation. *Any*
implementation, so we can start messing around with it! Even if it isn't
the one we eventually choose.
Once we have something we can add interrupt-thread support to it and
then move some of the more
On 28-Jun-99 Matthew Dillon wrote:
I think we desparately need a kernel threads implementation. *Any*
implementation, so we can start messing around with it! Even if it isn't
the one we eventually choose.
I don't suppose someone could post an explanation of how kernel
:
:I don't suppose someone could post an explanation of how kernel threads work
:could they? :)
:
:I sort of grasp the idea but I'm wondering what passes for context switches and
:stuff like that.. What does the switching between threads etc? Or am I
:completely off track?
:
:---
:Daniel O'Connor
In message pine.bsf.3.95.990627233124.8298o-100...@current1.whistle.com
Julian Elischer writes:
: now this is threads within the kernel, and not kernel support for user
: threads right?
Yes. That's right.
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe
In message xfmail.990628173909.dar...@dons.net.au Daniel J. O'Connor writes:
: I don't suppose someone could post an explanation of how kernel threads work
: could they? :)
Looks like it just does a fork like thing so it can do context
switches...
Warner
To Unsubscribe: send mail to majord
On Mon, 28 Jun 1999, Warner Losh wrote:
In message xfmail.990628173909.dar...@dons.net.au Daniel J. O'Connor
writes:
: I don't suppose someone could post an explanation of how kernel threads work
: could they? :)
Looks like it just does a fork like thing so it can do context
switches
Warner Losh wrote:
In message xfmail.990628173909.dar...@dons.net.au Daniel J. O'Connor writ
es:
: I don't suppose someone could post an explanation of how kernel threads wor
k
: could they? :)
Looks like it just does a fork like thing so it can do context
switches...
Warner
In message xfmail.990628173909.dar...@dons.net.au Daniel
J. O'Connor writes:
: I don't suppose someone could post an explanation of how kernel threads work
: could they? :)
In a nutshell, it appears to basically do an rfork. It then becomes
like any other process that is interrupted
78 matches
Mail list logo
