On Wed, 2012-01-04 at 15:59 -0800, Roland Dreier wrote:
> From: Roland Dreier <Roland Dreier roland@xxxxxxxxxxxxxxx>
>
> Doing alloc_page(GFP_KERNEL | __GFP_ZERO) to get pages used for data
> buffers wastes a lot of CPU clearing pages that will be quickly be
> overwritten by the actual data. However, for emulated control
> commands such as INQUIRY and so on, the code does assume that the
> buffer is zeroed.
>
> To avoid this CPU overhead, skip the __GFP_ZERO for commands that are
> actually moving data, ie cmds that have SCF_SCSI_DATA_SG_IO_CDB set.
>
> Signed-off-by: Roland Dreier <Roland Dreier roland@xxxxxxxxxxxxxxx>
> ---
> I'm not totally sure this is correct so please double-check my
> reasoning, but it is certainly true that clear_page shows up high
> on profiles running high throughput workloads, and there doesn't
> seem to be any good reason for that.
>
> drivers/target/target_core_transport.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
> index 0257658..419ffd6 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -3461,6 +3461,7 @@ transport_generic_get_mem(struct se_cmd *cmd)
> u32 length = cmd->data_length;
> unsigned int nents;
> struct page *page;
> + gfp_t zero_flag;
> int i = 0;
>
> nents = DIV_ROUND_UP(length, PAGE_SIZE);
> @@ -3471,9 +3472,11 @@ transport_generic_get_mem(struct se_cmd *cmd)
> cmd->t_data_nents = nents;
> sg_init_table(cmd->t_data_sg, nents);
>
> + zero_flag = cmd->se_cmd_flags & SCF_SCSI_DATA_SG_IO_CDB ? 0 : __GFP_ZERO;
> +
> while (length) {
> u32 page_len = min_t(u32, length, PAGE_SIZE);
> - page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> + page = alloc_page(GFP_KERNEL | zero_flag);
> if (!page)
> goto out;
>
Nice optimization!
I think this should be OK for SCF_SCSI_DATA_SG_IO_CDB, as i've only ever
seen strangeness here when not zeroing payloads for scsi-generic access
with SCF_SCSI_CONTROL_SG_IO_CDB.
Applied to lio-core, and will plan to queue this one up for v3.3 as
well.
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
