Re: [Xen-devel] about the network speed is too slow with vtd onXen-3.2

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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