On Thu, Aug 11, 2011 at 03:41:15PM +0200, Jens Axboe wrote: > On 2011-08-11 15:33, Vivek Goyal wrote: > > On Thu, Aug 11, 2011 at 09:42:16AM +0900, Kyungmin Park wrote: > >> 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? > > 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). > > > 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. > > >> 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. 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. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
