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.
>
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
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
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 (
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 (
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
6 matches
Mail list logo
