From: Jeff Garzik <jgarzik@pobox.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: Adrian Bunk <bunk@fs.tum.de>,
Manfred Spraul <manfred@colorfullife.com>,
linux-kernel@vger.kernel.org, peter_daum@t-online.de
Subject: Re: [2.4 patch] fix CONFIG_X86_L1_CACHE_SHIFT
Date: Mon, 8 Sep 2003 13:24:16 -0400 [thread overview]
Message-ID: <20030908172416.GA21226@gtf.org> (raw)
In-Reply-To: <20030908170751.GB27097@mail.jlokier.co.uk>
On Mon, Sep 08, 2003 at 06:07:51PM +0100, Jamie Lokier wrote:
> Adrian Bunk wrote:
> > > Why requires? On x86, the cpu caches are fully coherent. A too small L1
> > > cache shift results in false sharing on SMP, but it shouldn't cause the
> > > described problems.
> > >...
> >
> > Thanks for the correction, I falsely thought CONFIG_X86_L1_CACHE_SHIFT
> > does something different than it does.
>
> Were there any changes in the kernel to do with PCI MWI settings?
Yes; I've lost the specific context of the thread, but I have been
working on MWI/cacheline size issues along with IvanK for a while.
It's apparently the responsibility of the OS to fill in correct
PCI_CACHE_LINE_SIZE values, which in the case of generic kernels must be
filled in at runtime (pci_cache_line_size) not at compile-time
(SMP_CACHE_BYTES, etc.)
If you don't call pci_set_mwi() for a PCI device, which triggers the
cacheline size fixups and other checks, then using
Memory-Write-Invalidate (MWI) is definitely wrong. Or on an older
kernel, without the latest MWI changes, you could wind up programming
cacheline size to a value smaller than your current processor (again,
due to generic kernels).
If a feature/device/whatever can be programmed with cacheline size at
runtime, that will always be the preference. With a compile-time
constant for cacheline size, you are _guaranteed_ it will be wrong in
some case.
Jeff
next prev parent reply other threads:[~2003-09-08 17:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-07 20:36 [2.4 patch] fix CONFIG_X86_L1_CACHE_SHIFT Manfred Spraul
2003-09-08 14:20 ` Adrian Bunk
2003-09-08 17:07 ` Jamie Lokier
2003-09-08 17:24 ` Jeff Garzik [this message]
2003-09-08 19:45 ` Manfred Spraul
2003-09-09 14:49 ` Peter Daum
[not found] <20030907195557.GK14436@fs.tum.de.suse.lists.linux.kernel>
2003-09-07 20:30 ` Andi Kleen
2003-09-07 21:39 ` Dave Jones
2003-09-08 8:15 ` Peter Daum
[not found] ` <Pine.LNX.4.30.0309072228110.9987-100000@swamp.bayern.net.suse.lists.linux.kernel>
2003-09-07 21:57 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2003-09-07 19:55 Adrian Bunk
2003-09-07 20:59 ` Peter Daum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030908172416.GA21226@gtf.org \
--to=jgarzik@pobox.com \
--cc=bunk@fs.tum.de \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=peter_daum@t-online.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.