From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: Soeren Sonnenburg <kernel@nn7.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: prioritize PCI traffic ?
Date: Mon, 15 Jan 2007 20:23:30 +0530 [thread overview]
Message-ID: <45AB956A.5070103@linux.vnet.ibm.com> (raw)
In-Reply-To: <1168869630.15294.44.camel@localhost>
Soeren Sonnenburg wrote:
> On Mon, 2007-01-15 at 19:23 +0530, Vaidyanathan Srinivasan wrote:
>> Soeren Sonnenburg wrote:
>>> Dear all,
>>>
>>> is it possible to explicitly tell the kernel to prioritize PCI traffic
>>> for a number of cards in pci slots x,y,z ?
>>>
>>> I am asking as severe ide traffic causes lost frames when watching TV
>>> using 2 DVB cards + vdr... This is simply due to the fact that the PCI
>>> bus is saturated...
>> How do you know that the bus is saturated?
>
> I simply dd if=/dev/sd? of=/dev/null from four brand new sata-harddisks.
>
>> Are you streaming data to/from the ide hard disks/CDROM?
>
> yes.
>
>> Do you have DMAs 'ON' for the hard disks?
>
> yes.
Good.
>> Is everything just fine if there are no IDE traffic?
>
> yes.
Good.
>> Are you running 2.6 kernel with preempt 'ON'?
>
> no: CONFIG_PREEMPT_NONE=y
>
Try CONFIG_PREEMPT=y it may help. It made the system more responsive
for me.
>> Are all hardware on the same IRQ line? (shared interrupts)
>
> no: libata devices are on IRQ 16 and DVB devices on IRQ 20
Watch the interrupt count (/proc/interrupts) and interrupt rate,
that may give some clue on what is happening on the PCI bus.
>
>>> So, is any prioritizing of the PCI bus possible ?
>> The drivers + application indirectly can control priority on the
>> bus. Just reduce the priority of the application that uses IDE and
>> see if adjusting nice values of applications can change the scenario.
>
> That unfortunately did not help... no change...
33Mhz 32-bit PCI bus on typical PC can do around 100MB/sec... watch
your individual disk transfer rates and data rate to each DVB.
dd from 4 new SATA drive will probably fillup the bus. However,
depending on your motherboard, the integrated SATA controllers may
be on a different PCI bus than the one for the slots.
You can watch the lspci output to determine which bus the devices
are located.
--Vaidy
>
> Soeren
> --
> Sometimes, there's a moment as you're waking, when you become aware of
> the real world around you, but you're still dreaming.
next prev parent reply other threads:[~2007-01-15 14:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-15 11:07 prioritize PCI traffic ? Soeren Sonnenburg
2007-01-15 12:01 ` Andreas Mohr
2007-01-15 12:07 ` Soeren Sonnenburg
2007-01-15 13:53 ` Vaidyanathan Srinivasan
2007-01-15 14:00 ` Soeren Sonnenburg
2007-01-15 14:53 ` Vaidyanathan Srinivasan [this message]
2007-01-17 20:22 ` Hans-Peter Jansen
2007-01-27 0:32 ` Lee Revell
[not found] <fa.IZ3qyPHQu5qQWnA4jBWoHC54zJE@ifi.uio.no>
2007-01-15 14:24 ` Robert Hancock
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=45AB956A.5070103@linux.vnet.ibm.com \
--to=svaidy@linux.vnet.ibm.com \
--cc=kernel@nn7.de \
--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