Add new elevator ops for request hint

Hi Jens

Now eMMC device requires the upper layer information to improve the data performance and reliability.

. Context ID
Using the context information, it can sort out the data internally and improve the performance. The main problem is that it's needed to define "What's the context".
Actually I expect cfq queue has own unique ID but it doesn't so decide to use the pid instead

. Data Tag
Using the Data Tag (1-bit information), It writes the data at SLC area when it's hot data. So it can make the chip more reliable. First I expect the REQ_META but current ext4 doesn't pass the WRITE_META. only use the READ_META. so it needs to investigate it.

With these characteristics, it's helpful to teach the device. After some consideration. it's needed to pass out these information at request data structure.

Sample usage is following in drivers/mmc/card/block.c

       struct elevator_queue *e = md->queue.queue->elevator; struct request_hint hint;
       int ret;

       if (e->ops->elevator_get_req_hint_fn && req)
               ret = e->ops->elevator_get_req_hint_fn(req, &hint);

Thank you,
Kyungmin Park
---
Changelog v2
- Don't add the request member. instead add new elevator ops

---

block/cfq-iosched.c +0 -0

index 1f96ad6..5089f67 100644
@@ -3800,6 +3800,18 @@ queue_fail:
        return 1;

2011/8/11 Kyungmin Park <[email protected]>:

Quoted 18 lines

Hi Jens

Now eMMC device requires the upper layer information to improve the data performance and reliability.

. Context ID
Using the context information, it can sort out the data internally and improve the performance. The main problem is that it's needed to define "What's the context".
Actually I expect cfq queue has own unique ID but it doesn't so decide to use the pid instead

. Data Tag
Using the Data Tag (1-bit information), It writes the data at SLC area when it's hot data. So it can make the chip more reliable. First I expect the REQ_META but current ext4 doesn't pass the WRITE_META. only use the READ_META. so it needs to investigate it.

With these characteristics, it's helpful to teach the device. After some consideration. it's needed to pass out these information at request data structure.

Sample usage is following in drivers/mmc/card/block.c

Quoted 6 lines

       struct elevator_queue *e = md->queue.queue->elevator; struct request_hint hint;
       int ret;

       if (e->ops->elevator_get_req_hint_fn && req)
               ret = e->ops->elevator_get_req_hint_fn(req, &hint);

please put this to blkdev.h or similar. directly using it here is abnormal.

2011/8/11 Shaohua Li <[email protected]>:

Quoted 23 lines

2011/8/11 Kyungmin Park <[email protected]>:

Quoted 22 lines

Hi Jens

Now eMMC device requires the upper layer information to improve the data performance and reliability.

. Context ID
Using the context information, it can sort out the data internally and improve the performance. The main problem is that it's needed to define "What's the context".
Actually I expect cfq queue has own unique ID but it doesn't so decide to use the pid instead

. Data Tag
Using the Data Tag (1-bit information), It writes the data at SLC area when it's hot data. So it can make the chip more reliable. First I expect the REQ_META but current ext4 doesn't pass the WRITE_META. only use the READ_META. so it needs to investigate it.

With these characteristics, it's helpful to teach the device. After some consideration. it's needed to pass out these information at request data structure.

Sample usage is following in drivers/mmc/card/block.c

       struct elevator_queue *e = md->queue.queue->elevator;
       struct request_hint hint;
       int ret;

Quoted 4 lines

Quoted 2 lines

       if (e->ops->elevator_get_req_hint_fn && req)
               ret = e->ops->elevator_get_req_hint_fn(req, &hint);

please put this to blkdev.h or similar. directly using it here is abnormal.

BTW, we can add a (rq->cmd_flags & REQ_ELVPRIV) check here to make sure the request is at io scheduler.

Quoted 26 lines · Shaohua Li

2011/8/11 Shaohua Li <[email protected]>:

Quoted 25 lines

2011/8/11 Kyungmin Park <[email protected]>:

Quoted 24 lines

Hi Jens

Now eMMC device requires the upper layer information to improve the data performance and reliability.

. Context ID
Using the context information, it can sort out the data internally and improve the performance. The main problem is that it's needed to define "What's the context".
Actually I expect cfq queue has own unique ID but it doesn't so decide to use the pid instead

. Data Tag
Using the Data Tag (1-bit information), It writes the data at SLC area when it's hot data. So it can make the chip more reliable. First I expect the REQ_META but current ext4 doesn't pass the WRITE_META. only use the READ_META. so it needs to investigate it.

With these characteristics, it's helpful to teach the device. After some consideration. it's needed to pass out these information at request data structure.

Sample usage is following in drivers/mmc/card/block.c

       struct elevator_queue *e = md->queue.queue->elevator; struct request_hint hint;
       int ret;

       if (e->ops->elevator_get_req_hint_fn && req)
               ret = e->ops->elevator_get_req_hint_fn(req, &hint);

Quoted 4 lines

Quoted 2 lines

please put this to blkdev.h or similar. directly using it here is abnormal.

BTW, we can add a (rq->cmd_flags & REQ_ELVPRIV) check here to make sure the request is at io scheduler.

Yep, that should all go inside elv_get_request_context() or whatever is a good name. I don't want the hint structure, the caller can just check the request flags himself.

So something like:

int elv_get_request_context(struct request_queue *q, struct request *rq) {
       struct elevator_queue *e = q->elevator;

       if (!(rq->cmd_flags & REQ_ELVPRIV))
               return -1;

       if (e->ops->elevator_get_req_context_fn)
               return e->ops->elevator_get_req_context_fn(q, rq);

       return -1;
}

and then cfq/others adding that helper to provide the mapping.

Context is a bad name, but so is hint. Perhaps app_key would be better, as it more direcly infers what is being returned.

--
Jens Axboe

Quoted 29 lines · Jens Axboe

Quoted 28 lines · Shaohua Li

2011/8/11 Shaohua Li <[email protected]>:

Quoted 27 lines

2011/8/11 Kyungmin Park <[email protected]>:

Quoted 16 lines

Hi Jens

Now eMMC device requires the upper layer information to improve the data performance and reliability.

. Context ID
Using the context information, it can sort out the data internally and improve the performance. The main problem is that it's needed to define "What's the context".
Actually I expect cfq queue has own unique ID but it doesn't so decide to use the pid instead

. Data Tag
Using the Data Tag (1-bit information), It writes the data at SLC area when it's hot data. So it can make the chip more reliable. First I expect the REQ_META but current ext4 doesn't pass the WRITE_META. only use the READ_META. so it needs to investigate it.

With these characteristics, it's helpful to teach the device. After some consideration. it's needed to pass out these information at request data structure.

Quoted 8 lines

Sample usage is following in drivers/mmc/card/block.c

       struct elevator_queue *e = md->queue.queue->elevator;
       struct request_hint hint;
       int ret;

       if (e->ops->elevator_get_req_hint_fn && req)
               ret = e->ops->elevator_get_req_hint_fn(req, &hint);

please put this to blkdev.h or similar. directly using it here is abnormal.

Quoted 6 lines

Quoted 2 lines

BTW, we can add a (rq->cmd_flags & REQ_ELVPRIV) check here to make sure the request is at io scheduler.

Yep, that should all go inside elv_get_request_context() or whatever is a good name. I don't want the hint structure, the caller can just check the request flags himself.

Okay I see, it has to modify the filesystem to send the meta request, REQ_META flags to know it from device drivers.

Quoted 8 lines

So something like:

int elv_get_request_context(struct request_queue *q, struct request *rq)

{
       struct elevator_queue *e = q->elevator;

       if (!(rq->cmd_flags & REQ_ELVPRIV))
               return -1;

Also need to check the !rq case, mmc send the NULL request to wait the previous request wait.

Hi Jens

Now eMMC device requires the upper layer information to improve the data performance and reliability.

. Context ID
Using the context information, it can sort out the data internally and improve the performance. The main problem is that it's needed to define "What's the context".
Actually I expect cfq queue has own unique ID but it doesn't so decide to use the pid instead

. Data Tag
Using the Data Tag (1-bit information), It writes the data at SLC area when it's hot data. So it can make the chip more reliable.

First I expect the REQ_META but current ext4 doesn't pass the WRITE_META. only use the READ_META. so it needs to investigate it.

Quoted 10 lines · Kyungmin Park

Hi Jens

Now eMMC device requires the upper layer information to improve the data performance and reliability.

. Context ID
Using the context information, it can sort out the data internally and improve the performance. The main problem is that it's needed to define "What's the context".
Actually I expect cfq queue has own unique ID but it doesn't so decide to use the pid instead

Hi,

Can you please give little more details about the optimization you will do with this pid information?

Also what happens in the case of noop and deadline which don't maintain per process queues and can't provide this information.

Quoted 1 line

First I expect the REQ_META but current ext4 doesn't pass the WRITE_META. only use the READ_META. so it needs to investigate it.

So are you planning to later fix file systems to appropriately mark meta data requests?

Quoted 12 lines · Vivek Goyal

Quoted 10 lines · Kyungmin Park

Hi Jens

Now eMMC device requires the upper layer information to improve the data performance and reliability.

. Context ID
Using the context information, it can sort out the data internally and improve the performance. The main problem is that it's needed to define "What's the context".
Actually I expect cfq queue has own unique ID but it doesn't so decide to use the pid instead

Quoted 4 lines

Hi,

Can you please give little more details about the optimization you will do with this pid information?

It is provided in one of the other email threads for this patch.

Quoted 3 lines

Also what happens in the case of noop and deadline which don't maintain per process queues and can't provide this information.

It'll still work, it isn't really tied to the CFQ way of diviying things up.

Quoted 5 lines

Quoted 2 lines

First I expect the REQ_META but current ext4 doesn't pass the WRITE_META. only use the READ_META. so it needs to investigate it.

So are you planning to later fix file systems to appropriately mark meta data requests?

One thing that occured to me is that equating META to HOT is not necessarily a good idea. Meta data isn't necessarily more "hot" than regular data, it all depends on how it's being used. So I think it would be a lot more appropriate to pass down this information specifically, instead of overloading REQ_META.

Quoted 13 lines · Jens Axboe

Quoted 12 lines · Vivek Goyal

Quoted 10 lines · Kyungmin Park

Hi Jens

Now eMMC device requires the upper layer information to improve the data performance and reliability.

. Context ID
Using the context information, it can sort out the data internally and improve the performance. The main problem is that it's needed to define "What's the context".
Actually I expect cfq queue has own unique ID but it doesn't so decide to use the pid instead

Quoted 6 lines

Quoted 4 lines

Hi,

Can you please give little more details about the optimization you will do with this pid information?

It is provided in one of the other email threads for this patch.

Ok, thanks. I just read the other mail thread.

So the idea is that when multiple requests from multiple processes are in flight in driver, then using context information (pid in this case), driver can potentially do more efficient scheduling of these requests.

CFQ kind of already does that atleast for sync-idle queues as driver will see requests only from one context for extended period of time. So this optimization is primarily useful for random reads and writer queues where we do not idle. (Well if rotational=0, then we don't idle on even on sync-idle so not sure if these mmc chips set rotational=0 or not).

Quoted 7 lines

Quoted 4 lines

Also what happens in the case of noop and deadline which don't maintain per process queues and can't provide this information.

It'll still work, it isn't really tied to the CFQ way of diviying things up.

IIUC, for noop and deadline no optimizatoin will take place as no context information is available and things will default back to status quo? Atleast this patch implements hook only for CFQ.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

First I expect the REQ_META but current ext4 doesn't pass the WRITE_META. only use the READ_META. so it needs to investigate it.

Quoted 8 lines

Quoted 2 lines

So are you planning to later fix file systems to appropriately mark meta data requests?

One thing that occured to me is that equating META to HOT is not necessarily a good idea. Meta data isn't necessarily more "hot" than regular data, it all depends on how it's being used. So I think it would be a lot more appropriate to pass down this information specifically, instead of overloading REQ_META.

I think so. I guess it depends on what "HOT" means and filesystem should understand REQ_HOT and flag bio/req appropriately.

But if this optimization is especially targeted at meta data, then using REQ_META will make sense too.

Whatever flag it is (HOT, META), I am wondering why IO scheduler need to come into the picture for this information. This is kind of between filesystem and driver. As driver should see all the request flags, it should just be able to check for presence of flag and not call into elevator/IO scheduler.

On a side note, if we are willing to keep pid/iocontext information in struct request, then this optimization should work with noop/deadline too.