linux-kernel - Re: [RFC v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC controllers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Feb 2008 20:21:28 +0100
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	"Dan Williams" <dan.j.williams@...el.com>
Cc:	linux-kernel@...r.kernel.org,
	"Shannon Nelson" <shannon.nelson@...el.com>,
	"David Brownell" <david-b@...bell.net>, kernel@...32linux.org,
	"Francis Moreau" <francis.moro@...il.com>,
	"Paul Mundt" <lethal@...ux-sh.org>,
	"Vladimir A. Barinov" <vbarinov@...mvista.com>,
	"Pierre Ossman" <drzeus-list@...eus.cx>
Subject: Re: [RFC v2 5/5] Atmel MCI: Driver for Atmel on-chip MMC
 controllers

On Thu, 14 Feb 2008 11:34:03 -0700
"Dan Williams" <dan.j.williams@...el.com> wrote:

> On Thu, Feb 14, 2008 at 1:36 AM, Haavard Skinnemoen
> <hskinnemoen@...el.com> wrote:
> >  It's ok to use PIO for small and/or odd transfers like "read 2 bytes
> >  from this SDIO register", something that the mmc-block driver would
> >  never ask us to do. Using PIO for huge block data transfers will really
> >  hurt.
> 
> Except your testing has already shown that running out of descriptors
> rarely, if ever happens.  It just becomes an exercise in tuning the
> pool size, and letting this simple fall back mechanism be a safety net
> for the corner cases.

True...it's just that you normally expect _better_ performance when
increasing the size of the transfer. I'm just afraid that someone might
start tuning things elsewhere, only to find that crossing a certain
threshold gives a drastic reduction in performance. That would be
completely counter-intuitive.

> >  I think I'll try triggering the mmc tasklet from the DMA callback for
> >  now. Scheduling a tasklet from another tasklet should work just fine,
> >  right?
> 
> Yeah that should work because you are no longer under the channel lock.

Right. And if we insert the interrupt descriptor somewhere in the
middle instead of at the end, we should be able to submit a new batch
of descriptors before the previous batch is exhausted, thus maintaining
maximum throughput without any pauses.

I'll probably keep it simple at first though. Gotta save some
optimizations for later ;)

Haavard
--
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/