On Wed, April 18, 2012 9:25 am, Venkatraman S wrote: Hello, > a) At the top level, some policy decisions have to be made on what is > worth preempting for. > This implementation uses the demand paging requests and swap > read requests as potential reads worth preempting an ongoing long write. > This is expected to provide improved responsiveness for smarphones > with multitasking capabilities - example would be launch a email > application > while a video capture session (which causes long writes) is ongoing. > b) At the block handler, the higher priority request should be queued > ahead of the pending requests in the elevator > c) At the MMC block and core level, transactions have to executed to > enforce the rules of the MMC spec and make a reasonable tradeoff if the > ongoing command is really worth preempting. (For example, is it too close > to completing already ?). Do you have some profiling information (on real or synthetic scenarios) that may prove/show improvement in read latency for your design? It could be useful to use blktrace engine with some post processing to get per request (or per block) latency. Also you can gather some statistics about how often demand paging and swap read requests occurs during typical user scenarios. Without such statistical analysis we are risking to do hard work with zero benefits. Does this make sense? Thanks, Kostya Consultant for Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- 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
