Explain a bit of tricky code dealing with trims and how it prevents

starvation. These side effects aren't obvious without extremely
careful study, and are important to do just so.
This commit is contained in:
Warner Losh 2015-01-13 00:20:35 +00:00
parent 378c532c1f
commit 0ac665747d
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=277101
2 changed files with 20 additions and 0 deletions

View File

@ -1790,6 +1790,16 @@ adadone(struct cam_periph *periph, union ccb *done_ccb)
TAILQ_INIT(&queue);
TAILQ_CONCAT(&queue, &softc->trim_req.bps, bio_queue);
/*
* Normally, the xpt_release_ccb() above would make sure
* that when we have more work to do, that work would
* get kicked off. However, we specifically keep
* trim_running set to 0 before the call above to allow
* other I/O to progress when many BIO_DELETE requests
* are pushed down. We set trim_running to 0 and call
* daschedule again so that we don't stall if there are
* no other I/Os pending apart from BIO_DELETEs.
*/
softc->trim_running = 0;
adaschedule(periph);
cam_periph_unlock(periph);

View File

@ -3018,6 +3018,16 @@ dadone(struct cam_periph *periph, union ccb *done_ccb)
TAILQ_INIT(&queue);
TAILQ_CONCAT(&queue, &softc->delete_run_queue.queue, bio_queue);
softc->delete_run_queue.insert_point = NULL;
/*
* Normally, the xpt_release_ccb() above would make sure
* that when we have more work to do, that work would
* get kicked off. However, we specifically keep
* delete_running set to 0 before the call above to
* allow other I/O to progress when many BIO_DELETE
* requests are pushed down. We set delete_running to 0
* and call daschedule again so that we don't stall if
* there are no other I/Os pending apart from BIO_DELETEs.
*/
softc->delete_running = 0;
daschedule(periph);
cam_periph_unlock(periph);