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
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 pendin
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. Howeve
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 mas
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
hanks
Ravi
-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,
might be going on in 6.2 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.
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
here
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 mi_switche
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 code")
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'
C
, yes 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 thre
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 thre
PE) I 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
M
ay "run me" since we just 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: ma
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 sen
Hello,
I was browsing through the 7.x code and in particular looking at
kern/kern_switch.c and find ksegrp completely missing (I was looking for
setrunqueue).
Is the notion of process_scope vs system_scope out in 7.x?
Thanks
Ravi
___
freebsd-
ess/thread 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
Subje
Murty, 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
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. The
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" thre
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 t
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 t
24 matches
Mail list logo
