You shouldn't printk() at all in a normal per-interrupt path. You'll have to
use custom tracing if you're still at such an early debugging stage, or use
a trace macro which is compiled out and/or enabled by a Xen boot parameter
(like HVM_DBG_LOG()).
The only direction I'll contemplate for ordinary VT-d printk() tracing is to
have less of it!
-- Keir
On 17/6/08 02:28, "Zhang, Li" <li.zhang@xxxxxxxxx> wrote:
> If we delete this gdprintk, we can't get the debug infos.
>
>> -----Original Message-----
>> From: Cui, Dexuan
>> Sent: Monday, June 16, 2008 6:45 PM
>> To: 'Keir Fraser'; Zhang, Li; 'xen-devel@xxxxxxxxxxxxxxxxxxx'
>> Subject: RE: [Xen-devel] about the network speed is too slow with vtd
>> onXen-3.2
>>
>> Can we simply remove the gdprintk of "hvm_dpci_eoi"?
>> For a debug=y build (or we specify "guest_lvl=all" in grub), the message is
>> printed too frequently (maybe hundreds of times per second) when an assigned
>> E1000 NIC is transmitting data.
>>
>> diff -r 09dd5492651c xen/drivers/passthrough/io.c
>> --- a/xen/drivers/passthrough/io.c Mon Jun 09 17:18:27 2008 +0100
>> +++ b/xen/drivers/passthrough/io.c Wed Jun 11 12:20:02 2008 +0800
>> @@ -253,8 +253,6 @@ void hvm_dpci_eoi(struct domain *d, unsi
>> {
>> spin_unlock(&hvm_irq_dpci->dirq_lock);
>>
>> - gdprintk(XENLOG_INFO VTDPREFIX,
>> - "hvm_dpci_eoi:: mirq = %x\n", machine_gsi);
>> stop_timer(&hvm_irq_dpci->hvm_timer[domain_irq_to_vector(d,
>> machine_gsi)]);
>> if ( (ent == NULL) || !ent->fields.mask )
>> pirq_guest_eoi(d, machine_gsi);
>> diff -r 09dd5492651c xen/drivers/passthrough/vtd/iommu.c
>> --- a/xen/drivers/passthrough/vtd/iommu.c Mon Jun 09 17:18:27 2008 +0100
>> +++ b/xen/drivers/passthrough/vtd/iommu.c Wed Jun 11 12:17:46 2008 +0800
>> @@ -1696,7 +1696,7 @@ static int init_vtd_hw(void)
>> {
>> iommu = drhd->iommu;
>> if ( qinval_setup(iommu) != 0 )
>> - dprintk(XENLOG_ERR VTDPREFIX,
>> + dprintk(XENLOG_INFO VTDPREFIX,
>> "Queued Invalidation hardware not found\n");
>> }
>>
>> @@ -1704,7 +1704,7 @@ static int init_vtd_hw(void)
>> {
>> iommu = drhd->iommu;
>> if ( intremap_setup(iommu) != 0 )
>> - dprintk(XENLOG_ERR VTDPREFIX,
>> + dprintk(XENLOG_INFO VTDPREFIX,
>> "Interrupt Remapping hardware not found\n");
>> }
>>
>> -- Dexuan
>>
>>
>> -----Original Message-----
>> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
>> Sent: 2008年6月16日 18:33
>> To: Zhang, Li; xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-devel] about the network speed is too slow with vtd
>> onXen-3.2
>>
>> Have you considered not printing so much? After passthru is set up you
>> should only be logging on error conditions.
>>
>> -- Keir
>>
>> On 16/6/08 11:27, "Zhang, Li" <li.zhang@xxxxxxxxx> wrote:
>>
>>> Hi, Keir
>>> With 3.2-tree, if we assigned NIC to guest, we copy a file with 'scp'
>>> command. the speed shows only about 2M in 1000M LAN. It is because that
>>> when we add the guest_level, too many messages in the serial are
>>> printed. The patch 17509 of Xen unstable can be ported to this tree to
>>> fix it.
>>>
>>> diff -r b39b6ab402ee xen/drivers/char/serial.c
>>> --- a/xen/drivers/char/serial.c Fri Jun 13 13:59:22 2008 +0100
>>> +++ b/xen/drivers/char/serial.c Mon Jun 16 17:49:48 2008 +0800
>>> @@ -14,6 +14,9 @@
>>> #include <xen/sched.h>
>>> #include <xen/mm.h>
>>> #include <xen/serial.h>
>>> +
>>> +/* Never drop characters, even if the async transmit buffer fills. */
>>> +/* #define SERIAL_NEVER_DROP_CHARS 1 */
>>>
>>> static struct serial_port com[2] = {
>>> { .rx_lock = SPIN_LOCK_UNLOCKED, .tx_lock = SPIN_LOCK_UNLOCKED },
>>> @@ -81,22 +84,24 @@
>>>
>>> static void __serial_putc(struct serial_port *port, char c)
>>> {
>>> - int i;
>>> -
>>> if ( (port->txbuf != NULL) && !port->sync )
>>> {
>>> /* Interrupt-driven (asynchronous) transmitter. */
>>> +#ifdef SERIAL_NEVER_DROP_CHARS
>>> if ( (port->txbufp - port->txbufc) == SERIAL_TXBUFSZ )
>>> {
>>> - /* Buffer is full: we spin, but could alternatively drop
>>> chars. */
>>> + /* Buffer is full: we spin waiting for space to appear */
>>> + int i;
>>> while ( !port->driver->tx_empty(port) )
>>> cpu_relax();
>>> for ( i = 0; i < port->tx_fifo_size; i++ )
>>> port->driver->putc(
>>> port,
>>> port->txbuf[MASK_SERIAL_TXBUF_IDX(port->txbufc++)]);
>>> port->txbuf[MASK_SERIAL_TXBUF_IDX(port->txbufp++)] = c;
>>> + return;
>>> }
>>> - else if ( ((port->txbufp - port->txbufc) == 0) &&
>>> +#endif
>>> + if ( ((port->txbufp - port->txbufc) == 0) &&
>>> port->driver->tx_empty(port) )
>>> {
>>> /* Buffer and UART FIFO are both empty. */
>>>
>>> Thanks
>>> -Li
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home