[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061031193212.GC26625@flint.arm.linux.org.uk>
Date: Tue, 31 Oct 2006 19:32:12 +0000
From: Russell King <rmk+lkml@....linux.org.uk>
To: J?rn Engel <joern@...nheim.fh-wedel.de>
Cc: Pierre Ossman <drzeus-list@...eus.cx>,
Arnd Bergmann <arnd@...db.de>, Christoph Hellwig <hch@....de>,
Jiri Slaby <jirislaby@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Adrian Bunk <bunk@...sta.de>,
Dominik Brodowski <linux@...do.de>,
Harald Welte <laforge@...filter.org>,
Arjan van de Ven <arjan@...radead.org>,
Jean Delvare <khali@...ux-fr.org>
Subject: Re: feature-removal-schedule obsoletes
On Tue, Oct 31, 2006 at 04:57:56PM +0100, J?rn Engel wrote:
> On Sat, 28 October 2006 10:34:51 +0200, Pierre Ossman wrote:
> >
> > What should be used to replace it? The MMC block driver uses it to
> > manage the block device queue. I am not that intimate with the block
> > layer so I do not know the proper fix.
>
> Why does the MMC block driver use a thread? Is there a technical
> reason for this or could it be done in original process context as
> well, removing some code and useless cpu scheduler overhead?
As I understand it, there is no guarantee that a block drivers request
function will be called in process context - it could be called in
interrupt context.
The MMC subsystem needs process context to issue commands since the
process of issuing commands entails various sleeps. Hence why the
MMC block has its own process context.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
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