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
2012/1/28 Ryan Stone :
> Right now, whenever a thread is spawned, it inherits CPU affinity from
> its "parent" thread. I put parent in scare quotes because as far as I
> can tell, for a kernel thread the parent is essentially chosen
> arbitrarily (it looks like it is the most recent thread spawned
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 the
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
informati
On Wed, 28 Jan 2004, Julian Elischer wrote:
> the KSE stuff requires too much assistance from teh Userland Thread
> scheduler.
>
> HOWEVER it is possible that kthreads may one day be implemented as
> multiple threads of a single kernel process.. (but not yet)
John has been talking about doin
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
> wondering if it could be used within
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
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
> Are threads on FreeBSD 4.x implemented at the
> kernel level?
No, as far as I know, those are coming in FreeBSD 5.0 (which won't be out
for a while)
>
> 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 re
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
Kip Macy <[EMAIL PROTECTED]> wrote:
> The words "POSIX threads" only describes the API. It says nothing about
> the implementation. On FreeBSD they are non-preemptive user level threads
> (your main was never yielding so the thread you launched did not get any
> time). On Linux they are processes
> >
> > 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 ener
>
> 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
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
Hello,
> On Mon, Dec 27, 1999 at 09:34:49AM -0800, Kip Macy wrote:
>
> > The words "POSIX threads" only describes the API. It says nothing about
> > the implementation. On FreeBSD they are non-preemptive user level
threads
> > (your main was never yielding so the thread you launched did not get a
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
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.
>
> FreeBSD user threads have fairly high context switch overhead, especially
> when there are open fds that
On Mon, Dec 27, 1999 at 09:34:49AM -0800, Kip Macy wrote:
> The words "POSIX threads" only describes the API. It says nothing about
> the implementation. On FreeBSD they are non-preemptive user level threads
> (your main was never yielding so the thread you launched did not get any
> time).
Actu
The words "POSIX threads" only describes the API. It says nothing about
the implementation. On FreeBSD they are non-preemptive user level threads
(your main was never yielding so the thread you launched did not get any
time). On Linux they are processes sharing the same virtual memory space,
and a
47 matches
Mail list logo
