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]
Message-ID: <20080214202128.245adfd3@siona>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ