All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1484325542.2679.3.camel@sandisk.com>

diff --git a/a/1.txt b/N1/1.txt
index 28d5bf5..c2ecc59 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -3,58 +3,57 @@ On Fri, 2017-01-13 at 12:15 +0100, Hannes Reinecke wrote:
 > > This adds a set of hooks that intercepts the blk-mq path of
 > > allocating/inserting/issuing/completing requests, allowing
 > > us to develop a scheduler within that framework.
-> >=20
+> > 
 > > We reuse the existing elevator scheduler API on the registration
 > > side, but augment that with the scheduler flagging support for
 > > the blk-mq interfce, and with a separate set of ops hooks for MQ
 > > devices.
-> >=20
+> > 
 > > We split driver and scheduler tags, so we can run the scheduling
 > > independent of device queue depth.
-> >=20
+> > 
 > > Signed-off-by: Jens Axboe <axboe@fb.com>
->=20
+> 
 > [ .. ]
-> > @@ -823,6 +847,35 @@ static inline unsigned int queued_to_index(unsigne=
-d int queued)
+> > @@ -823,6 +847,35 @@ static inline unsigned int queued_to_index(unsigned int queued)
 > >  	return min(BLK_MQ_MAX_DISPATCH_ORDER - 1, ilog2(queued) + 1);
 > >  }
-> > =20
+> >  
 > > +static bool blk_mq_get_driver_tag(struct request *rq,
 > > +				  struct blk_mq_hw_ctx **hctx, bool wait)
 > > +{
-> > +	struct blk_mq_alloc_data data =3D {
-> > +		.q =3D rq->q,
-> > +		.ctx =3D rq->mq_ctx,
-> > +		.hctx =3D blk_mq_map_queue(rq->q, rq->mq_ctx->cpu),
-> > +		.flags =3D wait ? 0 : BLK_MQ_REQ_NOWAIT,
+> > +	struct blk_mq_alloc_data data = {
+> > +		.q = rq->q,
+> > +		.ctx = rq->mq_ctx,
+> > +		.hctx = blk_mq_map_queue(rq->q, rq->mq_ctx->cpu),
+> > +		.flags = wait ? 0 : BLK_MQ_REQ_NOWAIT,
 > > +	};
 > > +
 > > +	if (blk_mq_hctx_stopped(data.hctx))
 > > +		return false;
 > > +
-> > +	if (rq->tag !=3D -1) {
+> > +	if (rq->tag != -1) {
 > > +done:
 > > +		if (hctx)
-> > +			*hctx =3D data.hctx;
+> > +			*hctx = data.hctx;
 > > +		return true;
 > > +	}
 > > +
-> > +	rq->tag =3D blk_mq_get_tag(&data);
-> > +	if (rq->tag >=3D 0) {
-> > +		data.hctx->tags->rqs[rq->tag] =3D rq;
+> > +	rq->tag = blk_mq_get_tag(&data);
+> > +	if (rq->tag >= 0) {
+> > +		data.hctx->tags->rqs[rq->tag] = rq;
 > > +		goto done;
 > > +	}
 > > +
 > > +	return false;
 > > +}
 > > +
->=20
+> 
 > What happens with the existing request at 'rqs[rq->tag]' ?
 > Surely there is one already, right?
 > Things like '->init_request' assume a fully populated array, so moving
 > one entry to another location is ... interesting.
->=20
+> 
 > I would have thought we need to do a request cloning here,
 > otherwise this would introduce a memory leak, right?
 > (Not to mention a potential double completion, as the request is now at
@@ -66,4 +65,4 @@ Have you noticed that there are two .rqs[] arrays - tags->rqs and
 sched_tags->rqs[]? .init_request() loops over sched_tags->rqs[]. The
 above assignment applies to tags->rqs[].
 
-Bart.=
+Bart.
diff --git a/a/content_digest b/N1/content_digest
index a0f2d71..0a4c24d 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -16,58 +16,57 @@
  "> > This adds a set of hooks that intercepts the blk-mq path of\n"
  "> > allocating/inserting/issuing/completing requests, allowing\n"
  "> > us to develop a scheduler within that framework.\n"
- "> >=20\n"
+ "> > \n"
  "> > We reuse the existing elevator scheduler API on the registration\n"
  "> > side, but augment that with the scheduler flagging support for\n"
  "> > the blk-mq interfce, and with a separate set of ops hooks for MQ\n"
  "> > devices.\n"
- "> >=20\n"
+ "> > \n"
  "> > We split driver and scheduler tags, so we can run the scheduling\n"
  "> > independent of device queue depth.\n"
- "> >=20\n"
+ "> > \n"
  "> > Signed-off-by: Jens Axboe <axboe@fb.com>\n"
- ">=20\n"
+ "> \n"
  "> [ .. ]\n"
- "> > @@ -823,6 +847,35 @@ static inline unsigned int queued_to_index(unsigne=\n"
- "d int queued)\n"
+ "> > @@ -823,6 +847,35 @@ static inline unsigned int queued_to_index(unsigned int queued)\n"
  "> >  \treturn min(BLK_MQ_MAX_DISPATCH_ORDER - 1, ilog2(queued) + 1);\n"
  "> >  }\n"
- "> > =20\n"
+ "> >  \n"
  "> > +static bool blk_mq_get_driver_tag(struct request *rq,\n"
  "> > +\t\t\t\t  struct blk_mq_hw_ctx **hctx, bool wait)\n"
  "> > +{\n"
- "> > +\tstruct blk_mq_alloc_data data =3D {\n"
- "> > +\t\t.q =3D rq->q,\n"
- "> > +\t\t.ctx =3D rq->mq_ctx,\n"
- "> > +\t\t.hctx =3D blk_mq_map_queue(rq->q, rq->mq_ctx->cpu),\n"
- "> > +\t\t.flags =3D wait ? 0 : BLK_MQ_REQ_NOWAIT,\n"
+ "> > +\tstruct blk_mq_alloc_data data = {\n"
+ "> > +\t\t.q = rq->q,\n"
+ "> > +\t\t.ctx = rq->mq_ctx,\n"
+ "> > +\t\t.hctx = blk_mq_map_queue(rq->q, rq->mq_ctx->cpu),\n"
+ "> > +\t\t.flags = wait ? 0 : BLK_MQ_REQ_NOWAIT,\n"
  "> > +\t};\n"
  "> > +\n"
  "> > +\tif (blk_mq_hctx_stopped(data.hctx))\n"
  "> > +\t\treturn false;\n"
  "> > +\n"
- "> > +\tif (rq->tag !=3D -1) {\n"
+ "> > +\tif (rq->tag != -1) {\n"
  "> > +done:\n"
  "> > +\t\tif (hctx)\n"
- "> > +\t\t\t*hctx =3D data.hctx;\n"
+ "> > +\t\t\t*hctx = data.hctx;\n"
  "> > +\t\treturn true;\n"
  "> > +\t}\n"
  "> > +\n"
- "> > +\trq->tag =3D blk_mq_get_tag(&data);\n"
- "> > +\tif (rq->tag >=3D 0) {\n"
- "> > +\t\tdata.hctx->tags->rqs[rq->tag] =3D rq;\n"
+ "> > +\trq->tag = blk_mq_get_tag(&data);\n"
+ "> > +\tif (rq->tag >= 0) {\n"
+ "> > +\t\tdata.hctx->tags->rqs[rq->tag] = rq;\n"
  "> > +\t\tgoto done;\n"
  "> > +\t}\n"
  "> > +\n"
  "> > +\treturn false;\n"
  "> > +}\n"
  "> > +\n"
- ">=20\n"
+ "> \n"
  "> What happens with the existing request at 'rqs[rq->tag]' ?\n"
  "> Surely there is one already, right?\n"
  "> Things like '->init_request' assume a fully populated array, so moving\n"
  "> one entry to another location is ... interesting.\n"
- ">=20\n"
+ "> \n"
  "> I would have thought we need to do a request cloning here,\n"
  "> otherwise this would introduce a memory leak, right?\n"
  "> (Not to mention a potential double completion, as the request is now at\n"
@@ -79,6 +78,6 @@
  "sched_tags->rqs[]? .init_request() loops over sched_tags->rqs[]. The\n"
  "above assignment applies to tags->rqs[].\n"
  "\n"
- Bart.=
+ Bart.
 
-a428878982fa607342241a0c1dece7e9ee9c892fd02dd16ba78c92c788b0645e
+7982be3f3711dbf731ff2a58e7328c8cf66d8b3b851de382cf62ce524b8b7749

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.