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
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
that kernel process).
2012/1/28 Ryan Stone ryst...@gmail.com:
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
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
12 matches
Mail list logo
