SDIO Performance once again

[Dan Williams]

On Wed, 2009-02-18 at 14:43 -0500, Dan Williams wrote:
> On Wed, 2009-02-18 at 11:38 -0800, David Anders wrote:
> > Dan,
> > 
> > i can give it a try on my s3c2440 platform later this week to see if it improves performance.
> 
> That would be awesome, thanks!

As a follow-up, the patch I posted (slightly modified for flushing the
workqueue before destroying it) appears to send packets with no latency;
ie I print jiffies right before queuing the packet worker, and the
packet worker is executed immediately.

I'll post the patch to linux-wireless for 2.6.30, though it would be
good to get some more feedback on it.

Dan

> Dan
> 
> > 
> > thanks
> > Dave Anders
> > AML
> > 
> > 
> > --- On Wed, 2/18/09, Dan Williams <dcbw at redhat.com> wrote:
> > 
> > > From: Dan Williams <dcbw at redhat.com>
> > > Subject: Re: SDIO Performance once again
> > > To: "Cliff Cai" <cliffcai.sh at gmail.com>
> > > Cc: lists at dsh-elektronik.de, "Robin Getz" <rgetz at blackfin.uclinux.org>, libertas-dev at lists.infradead.org
> > > Date: Wednesday, February 18, 2009, 1:24 PM
> > > On Wed, 2009-02-11 at 11:36 +0800, Cliff Cai wrote:
> > > > I think this is caused by the mechanism to start a
> > > transfer from host to card.
> > > > see if_sdio_host_to_card() in if_sdio.c,it uses
> > > schedule_work to call
> > > > if_sdio_host_to_card_worker()
> > > > which start the transfer.
> > > 
> > > I spent a bit of time trying to figure out why if_sdio was
> > > written this
> > > way.  Couldn't find it.  ISTR having specific
> > > conversations with Pierre
> > > about using a worker thread to send data from host ->
> > > card, it might
> > > have had to do with locking or interrupt issues.
> > > 
> > > One method to reduce latency is to move the worker thread
> > > into its own
> > > workqueue.  It's currently on the generic workqueue,
> > > which could be
> > > waiting for other stuff.  So creating a private workqueue
> > > and using
> > > queue_work() to kick off the send might do the trick.
> > > 
> > > Anyone want to try the attached patch and see if it makes
> > > life better?
> > > Compile-tested, but not run tested.
> > > 
> > > Dan
> > > 
> > > > Cliff
> > > > 
> > > > On Wed, Feb 11, 2009 at 4:44 AM, Dominik S. Herwald
> > > > <lists at dsh-elektronik.de> wrote:
> > > > > Robin Getz schrieb:
> > > > >> On Mon 9 Feb 2009 08:09, Dominik S. Herwald
> > > pondered:
> > > > >>
> > > > >>> In the meantime I found out that my
> > > Problem seems to be related to the
> > > > >>> Kernel timer tick of 4ms
> > > > >>> (see my second posting on this list with
> > > the 4ms frames)...
> > > > >>> On Blackfin the Timer tick is set to
> > > 250Hz (4ms) by default. If I set it
> > > > >>>
> > > > >>> to 1000Hz,
> > > > >>> performance rises up to 11.2MBit/s
> > > performance!
> > > > >>>
> > > > >>
> > > > >> What happens when you select tickless?
> > > > >>
> > > > >> Select GENERIC_TIME &&
> > > GENERIC_CLOCKEVENTS && CYCLES_CLOCKSOURCE
> > > > >>
> > > > >> And it should show up as "Tickless
> > > System (Dynamic Ticks)".
> > > > >>
> > > > >> -Robin
> > > > >>
> > > > >>
> > > > >
> > > > > It performs the same (11MBit/s) as with 1000Hz
> > > Timer tick.
> > > > > On the Scope I can see a 1ms transfer interval
> > > instead of 4ms.
> > > > > There is still plenty of room in between the
> > > transfers on the SDIO Bus...
> > > > >
> > > > > If I set the Clock to 250Hz while these tickless
> > > options are active, the 4ms
> > > > > Interval is there again.
> > > > >
> > > > >
> > > > > I had a closer look at the Libertas Code - nearly
> > > everywhere in Libertas
> > > > > the Kernel Tick
> > > > > is only used for timeouts in the range of
> > > seconds. I did not see
> > > > > anything that could
> > > > > affect the transfer.  But I am really no Kernel
> > > Driver expert so I may
> > > > > have overlooked
> > > > > something...
> > > > >
> > > > > Best regards,
> > > > > Dominik
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > libertas-dev mailing list
> > > > > libertas-dev at lists.infradead.org
> > > > >
> > > http://lists.infradead.org/mailman/listinfo/libertas-dev
> > > > >
> > > > 
> > > > _______________________________________________
> > > > libertas-dev mailing list
> > > > libertas-dev at lists.infradead.org
> > > >
> > > http://lists.infradead.org/mailman/listinfo/libertas-dev
> > > _______________________________________________
> > > libertas-dev mailing list
> > > libertas-dev at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/libertas-dev
> > 
> > 
> >       
> > 
> > _______________________________________________
> > libertas-dev mailing list
> > libertas-dev at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/libertas-dev
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev