public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Anton Blanchard <anton@samba.org>,
	Jeff Garzik <jgarzik@pobox.com>,
	linux-kernel@vger.kernel.org
Subject: Re: pci_set_mwi() ... why isn't it used more?
Date: Thu, 30 Jan 2003 16:51:17 -0800	[thread overview]
Message-ID: <3E39C885.9060508@pacbell.net> (raw)
In-Reply-To: 20030131023419.A652@localhost.park.msu.ru

Ivan Kokshaysky wrote:
> On Thu, Jan 30, 2003 at 10:35:25AM -0800, David Brownell wrote:
> 
>>I think the first answer is better, but it looks like 2.5.59 will
>>set the pci cache line size to 16 bytes not 128 bytes in that case.
> 
> 
> Yes, and it looks dangerous as the device would transfer incomplete
> cache lines with MWI...

... while invalidating complete lines, yes that's what I meant about
it causing breakage.


>>Another option would be to do like SPARC64 and set the cacheline
>>sizes as part of DMA enable (which is what I'd first thought of).
>>And have the breakage test in the ARCH_PCI_MWI code -- something
>>that sparc64 doesn't do, fwiw.

It also sets latencies ... one could get the impression that most
PCI code on Linux hasn't been tuned for bus utilization yet!


> Actually I think there is nothing wrong if we'll try to be a bit
> more aggressive with MWI and move all of this into generic
> pci_set_master().
> To do it safely, we need
> - kind of "broken_mwi" field in the struct pci_dev for buggy devices,
>   it can be set either by PCI quirks or by driver before pci_set_master()
>   call;
> - arch-specific pci_cache_line_size() function/macro (instead of
>   SMP_CACHE_BYTES) that returns either actual CPU cache line size
>   or other safe value (including 0, which means "don't enable MWI");
> - check that the device does support desired cache line size, i.e.
>   read back the value that we've written into the PCI_CACHE_LINE_SIZE
>   register and if it's zero (or dev->broken_mwi == 1) don't enable MWI.
> 
> Thoughts?

Sounds plausible to me, but then I was asking about this because
it was evident there were a few more things going on here than I
was aware of.  You imply removing pci_{set,clear}_mwi() too.

I certainly agree that setting the cache line size automatically
should happen; and having that be correct means there's got to
be some arch dependent code.  That alone might help improve
throughput on PCI_DMA_TODEVICE, even on MWI-incapable devices.

It might be appropriate to make aggressively setting MWI be a
Kconfig (or boot) option.  That it "should not" be problematic
doesn't mean that some 2.6 users might not find trouble.

Also, benchmarks from folk with really busy PCI busses would
be interesting.  All this stuff can be tweaked with "setpci",
so they could be generated without needing kernel patches.

- Dave







      parent reply	other threads:[~2003-01-31  0:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-20 18:41 pci_set_mwi() ... why isn't it used more? David Brownell
2003-01-20 19:00 ` Jeff Garzik
2003-01-20 19:37   ` David Brownell
2003-01-30 13:52     ` Anton Blanchard
2003-01-30 16:25       ` David Brownell
2003-01-30 16:59         ` Ivan Kokshaysky
2003-01-30 18:35           ` David Brownell
2003-01-30 23:34             ` Ivan Kokshaysky
2003-01-31  0:11               ` Jeff Garzik
2003-01-31  0:51               ` David Brownell [this message]

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=3E39C885.9060508@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=anton@samba.org \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox