2013/1/14, Jaegeuk Kim <jaegeuk.kim@xxxxxxxxxxx>: > 2013-01-12 (토), 14:42 +0900, Namjae Jeon: >> From: Namjae Jeon <namjae.jeon@xxxxxxxxxxx> >> >> With f2fs having different writepages support for data, node and >> metapages. >> It will not be covered under the generic blk plug support. > > Could you show any improvement points with this patch? > > Currently, there is no reason to use blk plugging, since f2fs itself > gathers bios and then submit one big bio. > > Thanks, Hi Jaegeuk, There is no performance difference after introducing the block plugging in F2FS. We introduced this to reduced block lock contention for f2fs also. For every BIO request queuing part to the request queue: it needs to acquire lock-> spin_lock_irq(q->queue_lock); Even though the F2FS - already is handling the requests part very well. But still we can make use of blk_plug to reduce the block lock contention. When we introduce block plugging to F2FS part - all the requests will first be maintained on TASK basis and then pushed to the request queue. So, we do not have contention for the “queue lock”. If we consider the normal data write path: initial block plug is already taken care by generic write_pages(for f2fs readpages block plug is already taken care by default path of: read_pages()->mpage_readpages())), but we can optimize this write path also as we shared the in patch. Similarly, we introduced block plug for the node_page and meta_pages. Please share your opinion on this. Thanks! > > -- > Jaegeuk Kim > Samsung > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
