Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Jul 2001 15:52:47 +0000 (GMT)
From:      "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
To:        Bernd Walter <ticso@mail.cicely.de>
Cc:        Valentin Nechayev <netch@iv.nn.kiev.ua>, freebsd-smp@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject:   Re: libc_r locking... why?
Message-ID:  <Pine.LNX.4.20.0107011532020.1122-100000@www.everquick.net>
In-Reply-To: <20010701160738.A22683@cicely20.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sun, 1 Jul 2001 16:07:38 +0200
> From: Bernd Walter <ticso@mail.cicely.de>

> In -currents NOTEs I found this:
> # CPU_DISABLE_5X86_LSSER disables load store serialize (i.e. enables
> # reorder).  This option should not be used if you use memory mapped
> # I/O device(s).
> 
> A good sign that it may be at least possible on some CPUs.
> OK that's not an MP capable CPU.

This is an encouraging starting point... at least the issue is similar.
It's also in 4.3-R, so I can grep kernel source.

> What you need is an x86 guru or asume worst which will be the best
> thing anyway - otherwise you can't use it on other machines and
> sometimes programms get very old.

I thought that one had to assert "lock" to guarantee cache coherency...
an ugly hack would be to

	movl		(%pagebase,%index,1),%eax
	lock movl	%eax,(%pagebase,%index,1)

for every cache line in a page.  Ugly and slow... I'd much rather find out
if there's a way to tell the chipset "flush all pending writes in this
block, and ensure that both CPUs have the same view".

> I also don't know what the following is:
> # CPU_WT_ALLOC enables write allocation on Cyrix 6x86/6x86MX and AMD
> # K5/K6/K6-2 cpus.

Hmmmm.  Being concerned about x86 SMP, I've overlooked anything non-Intel.
Might be worth checking out what's there... I've oft learned what I wanted
via an indirect route.

> > Did you try to read MP chipsets white papers?

No.  I guess that I can give that a shot.

> I can't say very much about coherency problems on x86 but I can
> say for shure that you have to worry about this on every other MP
> platform including IA64.

Even if it's a non-issue on x86, I'd rather use macros to insert proper
code on ia64, axp (if I ever port to that), and go to nothing on x86 (if
that is indeed the correct behavior).

Looks like I need to do some digging on bus snooping, cache coherency,
read/write reordering, MTRRs, and APICs. :-)


Eddy

---------------------------------------------------------------------------

Brotsman & Dreger, Inc.
EverQuick Internet Division

Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

---------------------------------------------------------------------------

Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@brics.com>
To: blacklist@brics.com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <blacklist@brics.com>, or you are likely to be blocked.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.20.0107011532020.1122-100000>