[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4B1ED69F.4050609@microgate.com>
Date: Tue, 08 Dec 2009 16:43:43 -0600
From: Paul Fulghum <paulkf@...rogate.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] synclink_gt dropped transmit data bugfix
Andrew Morton wrote:
> On Tue, 08 Dec 2009 16:06:50 -0600
> Paul Fulghum <paulkf@...rogate.com> wrote:
>
>> + /* check required buffer space */
>> + bufs_needed = (size/DMABUFSIZE);
>> + if (size % DMABUFSIZE)
>> + ++bufs_needed;
>
> bufs_needed = DIV_ROUND_UP(size, DMABUFSIZE);
A reasonable substitution.
> That unsent_tbufs() call looks like it might be expensive.
unsent_tbufs() is called from isr_txeom() when the serial
transmitter has gone idle.
The common case is that the DMA buffers are empty
(all count fields reset to zero by DMA controller)
so the loop falls out on the first comparison.
The second most common case will be a single
data block added just after the DMA controller quits but
before the serial transmitter is idle. Here you only
need to back track the few buffers consumed by that block.
The degenerate case is a large burst of write calls
just after the DMA controller quits but before the
serial transmitter is idle. There are only 32 total
descriptors to iterate so worst case is still not that bad
and won't happen often. There is a single comparison per
descriptor and the descriptors are contained in system
memory and not card memory behind a PCI bridge.
The case of keeping the buffers full and transmitter
constantly active (sustained heavy traffic) results
in no calls to unsent_tbufs().
--
Paul Fulghum
MicroGate Systems, Ltd.
=Customer Driven, by Design=
(800)444-1982
(512)345-7791 (Direct)
(512)343-9046 (Fax)
Central Time Zone (GMT -5h)
www.microgate.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists