ia64/xen-unstable

changeset 8181:d4ab8e46136c

Blkif request notifications use generic ring req_event holdoff
mechanism rather than custom mechanism.

Signed-off-by: Keir Fraser <keir@xensource.com>
author kaf24@firebug.cl.cam.ac.uk
date Fri Dec 02 13:27:39 2005 +0100 (2005-12-02)
parents df68a9433492
children 265f68795ebf
files linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c xen/include/public/io/blkif.h
line diff
     1.1 --- a/linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c	Fri Dec 02 13:16:13 2005 +0100
     1.2 +++ b/linux-2.6-xen-sparse/drivers/xen/blkback/blkback.c	Fri Dec 02 13:27:39 2005 +0100
     1.3 @@ -498,10 +498,14 @@ static void make_response(blkif_t *blkif
     1.4           * notifications if requests are already in flight (lower overheads
     1.5           * and promotes batching).
     1.6           */
     1.7 -	if (!__on_blkdev_list(blkif) &&
     1.8 -	    RING_HAS_UNCONSUMED_REQUESTS(blk_ring)) {
     1.9 -		add_to_blkdev_list_tail(blkif);
    1.10 -		maybe_trigger_blkio_schedule();
    1.11 +	mb();
    1.12 +	if (!__on_blkdev_list(blkif)) {
    1.13 +		int more_to_do;
    1.14 +		RING_FINAL_CHECK_FOR_REQUESTS(blk_ring, more_to_do);
    1.15 +		if (more_to_do) {
    1.16 +			add_to_blkdev_list_tail(blkif);
    1.17 +			maybe_trigger_blkio_schedule();
    1.18 +		}
    1.19  	}
    1.20  
    1.21  	if (notify)
     2.1 --- a/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c	Fri Dec 02 13:16:13 2005 +0100
     2.2 +++ b/linux-2.6-xen-sparse/drivers/xen/blkfront/blkfront.c	Fri Dec 02 13:27:39 2005 +0100
     2.3 @@ -395,16 +395,11 @@ static inline void ADD_ID_TO_FREELIST(
     2.4  
     2.5  static inline void flush_requests(struct blkfront_info *info)
     2.6  {
     2.7 -	RING_IDX old_prod = info->ring.sring->req_prod;
     2.8 -
     2.9 -	RING_PUSH_REQUESTS(&info->ring);
    2.10 +	int notify;
    2.11  
    2.12 -	/*
    2.13 -         * Send new requests /then/ check if any old requests are still in
    2.14 -         * flight. If so then there is no need to send a notification.
    2.15 -         */
    2.16 -	mb();
    2.17 -	if (info->ring.sring->rsp_prod == old_prod)
    2.18 +	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&info->ring, notify);
    2.19 +
    2.20 +	if (notify)
    2.21  		notify_remote_via_irq(info->irq);
    2.22  }
    2.23  
     3.1 --- a/xen/include/public/io/blkif.h	Fri Dec 02 13:16:13 2005 +0100
     3.2 +++ b/xen/include/public/io/blkif.h	Fri Dec 02 13:27:39 2005 +0100
     3.3 @@ -12,11 +12,10 @@
     3.4  #include "ring.h"
     3.5  
     3.6  /*
     3.7 - * Front->back notifications: When enqueuing a new request, there is no
     3.8 - * need to send a notification if there are old requests still in flight
     3.9 - * (that is, old_req_prod != sring->rsp_prod). The backend guarantees to check
    3.10 - * for new requests after queuing the response for the last in-flight request.
    3.11 - * (NB. The generic req_event mechanism is not used for blk requests.)
    3.12 + * Front->back notifications: When enqueuing a new request, sending a
    3.13 + * notification can be made conditional on req_event (i.e., the generic
    3.14 + * hold-off mechanism provided by the ring macros). Backends must set
    3.15 + * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()).
    3.16   * 
    3.17   * Back->front notifications: When enqueuing a new response, sending a
    3.18   * notification can be made conditional on rsp_event (i.e., the generic