Before this thread on "cache coherence" and "memory consistency" goes
any further, I'd like to suggest a time-out to read something like
http://www-ece.rice.edu/~sarita/Publications/models_tutorial.ps.
A lot of what I'm reading has a grain of truth but isn't quite
right. This paper appeared as a
On Mon, Jul 12, 1999 at 10:38:03PM -0700, Mike Smith wrote:
I said:
than indirect function calls on some architectures: inline
branched code. So you still have a global variable selecting
locked/non-locked, but it's a boolean, rather than a pointer.
Your atomic macros are then {
Doug Rabson wrote:
On Mon, 12 Jul 1999, Peter Jeremy wrote:
Mike Haertel [EMAIL PROTECTED] wrote:
Um. FYI on x86, even if the compiler generates the RMW
form "addl $1, foo", it's not atomic. If you want it to
be atomic you have to precede the opcode with a LOCK
prefix 0xF0.
Although function calls are more expensive than inline code,
they aren't necessarily a lot more so, and function calls to
non-locked RMW operations are certainly much cheaper than
inline locked RMW operations.
This is a fairly key statement in context, and an opinion here would
count for a
:
: Although function calls are more expensive than inline code,
: they aren't necessarily a lot more so, and function calls to
: non-locked RMW operations are certainly much cheaper than
: inline locked RMW operations.
:
:This is a fairly key statement in context, and an opinion here would
:
: Although function calls are more expensive than inline code,
: they aren't necessarily a lot more so, and function calls to
: non-locked RMW operations are certainly much cheaper than
: inline locked RMW operations.
:
:This is a fairly key statement in context, and an opinion here
:I assumed too much in asking the question; I was specifically
:interested in indirect function calls, since this has a direct impact
:on method-style implementations.
Branch prediction caches are typically PC-sensitive. An indirect method
call will never be as fast as a direct call,
Mike Smith [EMAIL PROTECTED] wrote:
Although function calls are more expensive than inline code,
they aren't necessarily a lot more so, and function calls to
non-locked RMW operations are certainly much cheaper than
inline locked RMW operations.
This is a fairly key statement in context, and
:
:I'm not sure there's any reason why you shouldn't. If you changed the
:semantics of a stack segment so that memory addresses below the stack
:pointer were irrelevant, you could implement a small, 0-cycle, on-chip
:stack (that overflowed into memory). I don't know whether this
:semantic
:
:Based on general computer architecture principles, I'd say that a lock
:prefix is likely to become more expensive[1], whilst a function call
:will become cheaper[2] over time.
:...
:
:[1] A locked instruction implies a synchronous RMW cycle. In order
:to meet write-ordering guarantees
On Mon, Jul 12, 1999 at 07:09:58PM -0700, Mike Smith wrote:
Although function calls are more expensive than inline code,
they aren't necessarily a lot more so, and function calls to
non-locked RMW operations are certainly much cheaper than
inline locked RMW operations.
This is a fairly
:...
I would also like to add a few more notes in regards to write pipelines.
Write pipelines are not used any more, at least not long ones. The
reason is simply the cache coherency issue again. Until the data is
actually written into the L1 cache, it is acoherent.
Second answer: in the real world, we're nearly always hitting the
cache on stack operations associated with calls and argument passing,
but not less often on operations in the procedure body. So, in
^^^ typo
Urk. I meant to say "less often", delete the "not".
To Unsubscribe: send mail
This is a fairly key statement in context, and an opinion here would
count for a lot; are function calls likely to become more or less
expensive in time?
Ambiguous question.
First answer: Assume we're hitting the cache, taking no branch
mispredicts, and everything is generally going at "the
?
Also, try the latest -CURRENT and see if you can still get it stuck in
objtrm. I haven't had any luck so far in my simulation. If you still
get stuck in objtrm then try Alan's patch and see if that has an effect.
-Matt
Please try the attached patch.
Alan
Index: vm/vm_object.c
===
RCS file: /home/ncvs/src/sys/vm/vm_object.c,v
retrieving revision 1.158
diff -c -r1.158 vm_object.c
*** vm_object.c 1999/07/01 19:53:42 1.158
--- vm_object.c
an
interlock situation.
There is a way we can find out for sure. For any of you with processes
stuck in objtrm, see if you can gdb the kernel and get a backtrace
of that process to see if it might be in a state where a previous
call context is holding a PIP count on the object.
gdb -k
I can very reliable reproduce a process getting stuck in this state. The
box it is running on is a k6-2 400 with 128MB of ram and 500MB of swap.
When compiling mysql322-server with the compiler option of '-O2' or
'-O3', the build gets up to sql_yacc.cc. It churns on this file and
goes into the
is fine, but one cc1 process is stuck in "objtrm". Oh, and I hung a "cat
/proc/31624/map", too, trying to get some details (now stuck in "thrd_sleep").
So, am I just tripping over some old long-fixed bug? Or is this a new one
worth investigating? The kernel i
I've occasionally seen systems wedged in a similar state. I reported
my sighting of this on May 24th. Haven't seen it since.
The one bit of useful info I've learned since my report was that from
a talk with the program's author, I suspect the object in question may
have been created with
On Tuesday, 6th July 1999, Andrew Gallatin wrote:
Yes. say 'proc pidhashtbl[PID pidhash]-lh_first' in kgdb.
I suspect that it will be in exit() also..
Magic!
It looks like a plain old exit() to me.
(kgdb) proc pidhashtbl[27157pidhash]-lh_first
(kgdb) bt
#0 mi_switch () at
I have an old 486 here that I thrash to death occasionally. Well, at least
I try to get it to page to death. I started a make world last week and
forgot about it.
Today I noticed that it's been stuck for most of the week. Almost everything
is fine, but one cc1 process is stuck in "o
On recent -currents, one of our users has managed to wedge a job in
objtrm when its exiting. Anybody know what's causing this?
I've appended a stack trace of the offending process, as well as a
printout of the offending object. The machine seems otherwise
healthy.
I don't really understand
23 matches
Mail list logo
