On Mon, June 11, 2012 5:28 pm, Muthu Kumar wrote: > On Mon, Jun 11, 2012 at 2:19 PM, Muthu Kumar <muthu.lkml@xxxxxxxxx> wrote: >> On Fri, Jun 1, 2012 at 11:55 AM, Maya Erez <merez@xxxxxxxxxxxxxx> wrote: >>> The write packing control will ensure that read requests latency is >>> not increased due to long write packed commands. >>> >>> The trigger for enabling the write packing is managing to pack several >>> write requests. The number of potential packed requests that will >>> trigger >>> the packing can be configured via sysfs by writing the required value >>> to: >>> /sys/block/<block_dev_name>/num_wr_reqs_to_start_packing. >>> The trigger for disabling the write packing is fetching a read request. >>> >> >> If it is applicable only to MMC why do we have this sysfs attr for all >> block devices? > > Just to be clear, please create a directory, say mmc, under > /sys/block/<dev>/ and create the attr inside that. > > You can refer to dm (dm-sysfs.c) for sample implementation. > > Regards, > Muthu > Hi Muthu, I released a new version of this patch which doesn't include this change yet. I understand why you think it would be best to distinguish the MMC specific attribute from the general block devices attributes. However, since this attribute is created only for the MMC block device, other block devices won't be aware of it. Therefore, it doesn't necessarily require a separation to a different folder. Currently there is another MMC specific attribute (force_ro) which is also created in the root directory. I think it would be better to also create the num_wr_reqs_to_start_packing in the same folder as force_ro and not make it an exceptional attribute in its location and the code that handles it. I would appreciate your opinion on that. Thanks, Maya -- Sent by consultant of 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
