[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070916.123158.92582301.davem@davemloft.net>
Date: Sun, 16 Sep 2007 12:31:58 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: hadi@...erus.ca
Cc: herbert@...dor.apana.org.au, netdev@...r.kernel.org,
kaber@...sh.net, dada1@...mosbay.com, johnpol@....mipt.ru
Subject: Re: [RFC][NET_SCHED] explict hold dev tx lock
From: jamal <hadi@...erus.ca>
Date: Sun, 16 Sep 2007 12:14:34 -0400
> Changes:
> I made changes to the code path as defined in the patch included to
> and noticed a slight increase (2-3%) in performance with both e1000 and
> tg3; which was a relief because i thought the spinlock_irq (which is
> needed because some drivers grab tx lock in interupts) may have negative
> effects. The fact it didnt reduce performance was a good thing.
> Note: This is the highest end machine ive ever laid hands on, so this
> may be misleading.
>
> So - what side effects do people see in doing this? If none, i will
> clean it up and submit.
I tried this 4 years ago, it doesn't work. :-)
Many drivers, particularly very old ones that PIO packets into
a device which can take a long time, absolutely depend upon
interrupts being enabled fully during ->hard_start_xmit()
so that other high periority devices (such as simpler serial
controllers) can have their interrupts serviced during this
slow operation.
I don't think we want to do it anyways, whatever performance
we gain from it is offset by the badness of disabling interrupts
during this reasonably length stretch of code.
The -rt folks as a result would notice this too and spank us :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists