Yes, that's what I was thinking. Just look at what's running on the remote CPU.
Thanks Jeff and John.
Ravi
-Original Message-
From: John Baldwin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2008 8:38 AM
To: freebsd-hackers@freebsd.org
Cc: Murty, Ravi; [EMAIL PROTECTED
Hello All,
I have been playing with ULE in 8.0 and while staring at tdq_notify noticed an
interesting (and what seems like a typo) problem.
The intention of the function is obvious, send an IPI to notify the remote CPU
of some new piece of work. In the case where there is no IPI currently
Hello All,
This is something I've been trying to figure out in the last couple of hours,
but can't seem to understand.
Sched_thread_priority() updates a threads priority to prio. If the thread is
on the RUNQ, we have to pull it out and put it back at a different spot on the
same queue.
Hello All,
I was browsing the ULE 8.0 scheduler code and happen to find something
interesting. This might be intentional; since I don't think it is that
big a deal and is certainly not a bug.
In the implementation of sched_affinity - which from what I understand
gets called when the cpuset
Hello,
I was wondering what all these different priority related fields in a
thread structure meant. This is the 8.0 kernel tree.
Thanks
Ravi
Td_base_pri
Td_user_pri
Td_base_user_pri
Td_priority
___
freebsd-hackers@freebsd.org mailing
before I spend the time to migrate to 7.0.
Thanks
Ravi
-Original Message-
From: Kris Kennaway [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2008 2:04 PM
To: [EMAIL PROTECTED]
Cc: Murty, Ravi; freebsd-hackers@freebsd.org
Subject: Re: Bug in calcru in he 6.2 and 6.3 kernels
Xin LI
-Original Message-
From: Jeremy Chadwick [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 20, 2008 6:59 AM
To: Murty, Ravi
Cc: Kris Kennaway; [EMAIL PROTECTED]; freebsd-hackers@freebsd.org
Subject: Re: Bug in calcru in he 6.2 and 6.3 kernels
On Sun, Jul 20, 2008 at 06:51:22AM -0700, Murty, Ravi wrote
Hello All,
Just a quick question: Why does this function (ipi_nmi_handler) execute
a atomic_load_acq_int(ipi_nmi_pending). Following this it calls
atomic_clear_int to clear itself out of this mask. I can't think of why
the CPU would reorder these instructions knowing there is a dependency
Hello everyone,
Finally found what my last problem was. We were running top in a loop
and running some workloads that called sched_bind() to bind threads to
specific CPUs. The problem was that (and I am using ULE) sched_bind
calls a function to notify another CPU of a thread and then
Hello All,
I have a rather simple question. I am running the 6.2 kernel and calru
is called when top is run in a loop. One of the things calcru does is
walk to threads of a process and checks if the thread is running and if
it asserts that its tdoncpu field be anything but NOCPU. In our case,
Hello Everybody,
This is a basic question - I've noticed this code in the kernel and
sched_4bsd.c which basically says assert that I am running on that I am
not on the runq.
For instance, in mi_switch() (kern_sync.c) there is an assert
KASSERT(!TD_ON_RUNQ(td), (mi_switch: called by old
Hi,
When a thread is being switched out and it is being preempted (e.g. time
quantum expires), why does sched_switch hold it on the current cpu? i.e.
why does the code see that it was preempted and put it back on the same
queue?
In other cases it looks to see if it can be migrated and the
this is 6.2
Thanks much,
Ravi
-Original Message-
From: Julian Elischer [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 08, 2008 3:28 PM
To: Murty, Ravi
Cc: freebsd-hackers@freebsd.org
Subject: Re: SW_PREEMPT and cpu runq
Murty, Ravi wrote:
Hi,
When a thread is being switched out
Oh, I find this happens only in ULE -- during sched_switch(), it sets
KEF_HOLD and then calls setrunqueue(). This ensures that the thread does
not migrate on preemptions.
Ravi
-Original Message-
From: Murty, Ravi
Sent: Thursday, May 08, 2008 3:48 PM
To: 'Julian Elischer'
Cc: freebsd
Hello All,
Looking through the scheduler code (kern_switch.c) and two functions
that stood out were the following:
1. maybe_preempt_in_ksegrp - this function basically checks if the
thread being made runnable should preempt another thread that is part of
the same ksegrp. This makes
established
that I am higher priority than what's running on the CPU.
Ravi
-Original Message-
From: Julian Elischer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 30, 2008 2:27 PM
To: Murty, Ravi
Cc: freebsd-hackers@freebsd.org
Subject: Re: maybe_preempt_in_ksegrp
Murty, Ravi wrote:
Hello
don't
see this call (maybe_preempt_in_ksegrp) ever getting called :).
Thanks
ravi
-Original Message-
From: Julian Elischer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 30, 2008 3:52 PM
To: Murty, Ravi
Cc: freebsd-hackers@freebsd.org
Subject: Re: maybe_preempt_in_ksegrp
Murty, Ravi
Hello All,
I am working on the 6.2 FreeBSD code base and has a couple of simple
questions. The thread structure defines two priority fields
td_base_pri and td_priority while a ksegrp defines kg_user_pri and
kg_pri_class.
1. Since a ksegrp can have multiple process scope threads, how
Hello,
When a thread cannot get a mutex (default mutex) and needs to be
blocked, is it really put to sleep? From looking at the code it appears
that it is inhibited (TD_SET_LOCK) but isn't really put to sleep.
1. Why isn't it put to sleep - why can't it be treated the same?
2.
, Ravi
Cc: freebsd-hackers@freebsd.org
Subject: Re: Do you really sleep when blocked on a mutex?
Murty, Ravi wrote:
Hello,
When a thread cannot get a mutex (default mutex) and needs to be
blocked, is it really put to sleep? From looking at the code it
appears
that it is inhibited
running on a CPU be swapped
out, do they suspend the threads before they pull out memory from
underneath them?
Thanks
Ravi
-Original Message-
From: Julian Elischer [mailto:[EMAIL PROTECTED]
Sent: Monday, April 21, 2008 1:33 PM
To: Murty, Ravi
Cc: freebsd-hackers@freebsd.org
Subject: Re: Do
Hello All,
I was looking at the code that creates a new process (fork) with a
single thread coming out on the other side. I can't figure out a couple
of things.
1. Why is the md_spinlock_count for the new thread set to 1 and not
to 0. This happens in cpu_fork and cpu_set_upcall under
Hello All,
I was looking at the code that creates a new process (fork) with a
single thread coming out on the other side. I can't figure out a couple
of things.
1. Why is the md_spinlock_count for the new thread set to 1 and not
to 0. This happens in cpu_fork and cpu_set_upcall under
23 matches
Mail list logo
