24.02.2012 19:05, Attilio Rao пишет:
> 2012/2/24, Eugene Grosbein :
>> 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
>>> to
28.01.2012 20:22, Attilio Rao пишет:
> 2012/1/28 Ryan Stone :
>> On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao 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
2012/2/24, Eugene Grosbein :
> 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 wi
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 net
2012/2/24, Eugene Grosbein :
> 28.01.2012 20:22, Attilio Rao пишет:
>
>> 2012/1/28 Ryan Stone :
>>> On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao
>>> wrote:
I think what you found out is very sensitive.
However, the patch is not correct as you cannot call
cpuset_setthread() with thr
On Sat, Jan 28, 2012 at 8:22 AM, Attilio Rao 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 cores
were lightly
On Sat, Jan 28, 2012 at 02:39:17PM +0100, Attilio Rao wrote:
> 2012/1/28 Attilio Rao :
> > 2012/1/28 Ryan Stone :
> >> On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao wrote:
> >>> I think what you found out is very sensitive.
> >>> However, the patch is not correct as you cannot call
> >>> cpuset_se
2012/1/28 Attilio Rao :
> 2012/1/28 Ryan Stone :
>> On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao 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 tha
2012/1/28 Ryan Stone :
> On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao 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 fix
On Fri, Jan 27, 2012 at 10:41 PM, Attilio Rao 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 apparently I include
the most recent 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 resul
el 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
intended. For example, I ad
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 a
- Original Message
> From: Shrikanth Kamath
> 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
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)
{
...
.
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(
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
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
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
n talking about doing 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 ful
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,
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 s
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
>
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 kerne
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 c
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
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 handle
* 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 in
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 interru
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
> implemen
see for myself that threads are really
> 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 wh
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 anything
* 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
> main()
> {
>
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
main()
{
if (rfork( RFPROC | RFNOWAIT | RFMEM | RFSIGSHARE ) > 0)
{
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 t
* 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
> mu
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
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 flag
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
(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
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
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
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 mention
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
>
>
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 version of the patch can be found at:
http
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 b
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
C
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 cop
On Mon, 3 Jan 2000, Wes Peters wrote:
> Kip Macy wrote:
> >
> > >
> > > 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,
Kip Macy wrote:
>
> >
> > 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 on vfs_a
>
> 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 on vfs_aio.c is 1997, suggesting
to me
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 processors.
> For I/O bound activities you want user level threads so you can minimi
> >
> > 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
> 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.
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 i
> > 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 t
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
> > wo
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 brai
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
or 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).
> > On Linux they are processes sharing the same virtual memory space,
> > and are referred to as kernel threads. For co
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 a
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 (e
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 places.
Is this recently, or a while ago? FreeBSD use
fds that get polled on each context switch. Kernel
> threads are actually faster in many circumstances.
Not Linux threads. The linux threads implementation, as parts of its
synchronization methods, disables interrupts. When Lyris previously used
one thread for each connection, performance on
un. With just 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 kerne
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
ny more.
Why?
I thougt POSIX threads would be kernel threads and therefor
every thread gets a bit cpu time.
Any ideas?
Please answer to me directly as I'm not on the list.
Stefen
This programm was compiled with:
gcc -pthread -o pthread pthread.c
#include
#include
#include
void print(
this is the small realtime kernel mentionned at usenix.
It is not a replacement for Unix/BSD.
On Thu, 23 Dec 1999, Chuck Robey wrote:
> On Thu, 23 Dec 1999, scott wrote:
>
> > I've found
> >
> > http://www.cornfed.com/pk
> >
> > looks weird, but s
On Thu, 23 Dec 1999, scott wrote:
> I've found
>
> http://www.cornfed.com/pk
>
> looks weird, but says it will do kernel threads for FreeBSD.
I looked to see this, but didn't. It does say it has a "BSD" license, and
it says it *cross*builds* under FreeBS
I've found
http://www.cornfed.com/pk
looks weird, but says it will do kernel threads for FreeBSD. It
replaces the kernel, though, so I don't know how it works with FreeBSD
hardware drivers.
I was bit by soddy mysql performance when the number of concurrent
clients and queries was
ps went up another 30%.
All against a 32M cache SCSI-SCSI RAID5 controller with 6 10krpm drives.]
I periodically hear reference to kernel threads - but from what I can tell
from following these lists for a couple months, and also searching the
archives, kernel threads aren't quite "there
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 interrupte
In message "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...
Warner
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
Warner Losh wrote:
> In message "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...
>
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
On Mon, 28 Jun 1999, Warner Losh wrote:
> In message "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
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
In message "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...@freebsd.o
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
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 freebsd-hackers" in the body of the message
:
: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?
:
:---
:Danie
:
: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?
:
:---
:Danie
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 explan
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 explan
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 o
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 o
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?
jul
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?
juli
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 p
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 po
91 matches
Mail list logo
