Re: Disabling interrupts before block device request call

Re: Disabling interrupts before block device request call

[Jens Axboe]

On Fri, May 25 2001, Alexandr Andreev wrote:
> Hi, list
> In ll_rw_block.c, before calling block device specific request function 
> ( i mean do_hd_request, do_ftl_request, ... ) the io_request_lock is 
> locking, and all interrupts are disabling. I know, that request handler 
> routine have to be atomic, but when we read data from a flash device ( 
> for example ) we use a timeouts. Where do we have to enable timer 
> interrupts, or should we disable all interrupts?

Even with dropping io_request_lock, it's not recommended to sleep inside
the request_fn. WIth plugging, you are basically preventing the other
plugged queues from being run until you return.

You could use a timer or similar to call you on a specified timeout
instead.

-- 
Jens Axboe

Disabling interrupts before block device request call

[Alexandr Andreev]

Hi, list
In ll_rw_block.c, before calling block device specific request function 
( i mean do_hd_request, do_ftl_request, ... ) the io_request_lock is 
locking, and all interrupts are disabling. I know, that request handler 
routine have to be atomic, but when we read data from a flash device ( 
for example ) we use a timeouts. Where do we have to enable timer 
interrupts, or should we disable all interrupts?

Re: Why timer interrupt is disabled?

[David Woodhouse]

andreev@niisi.msk.ru said:
>  It may happen that one  CPU is reading and other CPU is writing data
> at the same time. So, the  flash memory can return status value
> instead of data, for example. Does  the chip->mutex lock provides
> necessary synchronization?

Yes. The flash driver is required to make that work correctly. The (blkdev)
request functions aren't required to be reentrant anyway, I believe.

> I look at the other block device drivers code and found, that
> io_request  handlers do sti() in some cases. If you still don`t want
> to do it, we  could use a softirq. In the do_fd_request(), the "bottom
> halves" is used  for example. We could use a "bottom halves" or even a
> tasklet in our  case. What do you think about this?

Take a look at the way it's done by the mtdblock device, with a kernel 
thread.

--
dwmw2

Re: Why timer interrupt is disabled?

[Alexandr Andreev]

I had asked this question to linux-kernel@vger.kernel.org and there is 
the answer:

Jens Axboe wrote:

>On Fri, May 25 2001, Alexandr Andreev wrote:
>
>>Hi, list
>>In ll_rw_block.c, before calling block device specific request function 
>>( i mean do_hd_request, do_ftl_request, ... ) the io_request_lock is 
>>locking, and all interrupts are disabling. I know, that request handler 
>>routine have to be atomic, but when we read data from a flash device ( 
>>for example ) we use a timeouts. Where do we have to enable timer 
>>interrupts, or should we disable all interrupts?
>>
>
>Even with dropping io_request_lock, it's not recommended to sleep inside
>the request_fn. WIth plugging, you are basically preventing the other
>plugged queues from being run until you return.
>
>You could use a timer or similar to call you on a specified timeout
>instead.
>
... and nevertheless, this is a bad idea to unlock the io_request_lock 
inside the do_ftl_request. What about the SMP? It may happen that one 
CPU is reading and other CPU is writing data at the same time. So, the 
flash memory can return status value instead of data, for example. Does 
the chip->mutex lock provides  necessary synchronization?
I look at the other block device drivers code and found, that io_request 
handlers do sti() in some cases. If you still don`t want to do it, we 
could use a softirq. In the do_fd_request(), the "bottom halves" is used 
for example. We could use a "bottom halves" or even a tasklet in our 
case. What do you think about this?

Re: Disabling interrupts before block device request call

[Alexandr Andreev]

Jens Axboe wrote

>
>Even with dropping io_request_lock, it's not recommended to sleep inside
>the request_fn. WIth plugging, you are basically preventing the other
>plugged queues from being run until you return.
>
>You could use a timer or similar to call you on a specified timeout
>instead.
>
Does it mean, that if i need timer interrupts in my block device driver, 
i need to do sti() instead of unlock io_request_lock? Is there any 
common rule for device drivers in such case?