; value and provides a possibility to wake it via a timer for the
> polling scenarios. That allows to simplify the sdio logic
> significantly.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc"
ction which avoids the check
> for the thread is required.
>
> Add a function, which just monitors the hard irq parts and ignores the
> threaded handlers.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra
--
To unsubscribe from this list: send the line "unsubsc
On Wed, Jan 15, 2014 at 03:19:27PM +0800, Dong Aisheng wrote:
> On Mon, Jan 13, 2014 at 8:04 PM, Peter Zijlstra wrote:
> > On Thu, Dec 26, 2013 at 03:58:20PM +0800, Dong Aisheng wrote:
> >> > It's strange that this issue did not happen on kernel 3.10.17 with the
&g
On Thu, Dec 26, 2013 at 03:58:20PM +0800, Dong Aisheng wrote:
> > It's strange that this issue did not happen on kernel 3.10.17 with the same
> > code. And looking at the code, before call spin_lock we already disable the
> > mmc
> > controller irq, per on my understanding, the deadlock given by l
On Wed, 2009-11-18 at 19:31 +0900, Minchan Kim wrote:
> >
> > Sure some generic blocklevel infrastructure might work, _but_ you cannot
> > take away the responsibility of determining the amount of memory needed,
> > nor does any of this have any merit if you do not limit yourself to that
> > amount
On Wed, 2009-11-18 at 09:01 +0900, Minchan Kim wrote:
> Hi, Peter.
>
> First of all, Thanks for the commenting.
>
> On Wed, Nov 18, 2009 at 5:47 AM, Peter Zijlstra wrote:
> > On Tue, 2009-11-17 at 21:51 +0900, Minchan Kim wrote:
> >> I think it's because memp
On Tue, 2009-11-17 at 21:51 +0900, Minchan Kim wrote:
> I think it's because mempool reserves memory.
> (# of I/O issue\0 is hard to be expected.
> How do we determine mempool size of each block driver?
> For example, maybe, server use few I/O for nand.
> but embedded system uses a lot of I/O.
