Re: MD-RAID: Use seq_putc() in three status functions?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>> So back to the original task for you: Show me in the generated output where the benefits are.

I can offer another bit of information for this software development discussion.

The following build settings were active in my "Makefile" for this Linux test case.

…
HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes -O0 -fomit-frame-pointer -std=gnu89
…


The afffected source files can be compiled for the processor architecture "x86_64"
by a tool like "GCC 6.2.1+r239849-1.5" from the software distribution
"openSUSE Tumbleweed" with the following command example.

my_original=${my_build_dir}unchanged/test/ \
&& my_fixing=${my_build_dir}patched/test/ \
&& mkdir -p ${my_original} ${my_fixing} \
&& my_cc=/usr/bin/gcc-6 \
&& my_module=drivers/md/raid1.s \
&& git checkout next-20161014 \
&& make -j6 O="${my_original}" CC="${my_cc}" HOSTCC="${my_cc}" allmodconfig "${my_module}" \
&& git checkout next_usage_of_seq_putc_in_md_raid_1 \
&& make -j6 O="${my_fixing}" CC="${my_cc}" HOSTCC="${my_cc}" allmodconfig "${my_module}" \
&& diff -u "${my_original}${my_module}" "${my_fixing}${my_module}" > "${my_build_dir}assembler_code_comparison_$(date -I)_3.diff"


The generated file got the size "25.4 KiB" this time. I guess that only
the following two diff hunks are interesting then to show desired effects
for the suggested software refactoring around data output of a single character
(instead of a similar string).


…
@@ -4402,10 +4402,6 @@
 .LC19:
 	.string	"%s"
 	.zero	61
-	.align 32
-.LC20:
-	.string	"]"
-	.zero	62
 	.text
 	.p2align 4,,15
 	.type	raid1_status, @function
@@ -4564,8 +4560,8 @@
 	movq	$rcu_lock_map, %rdi	#,
 	call	lock_release	#
 	movq	%r14, %rdi	# seq,
-	movq	$.LC20, %rsi	#,
-	call	seq_printf	#
+	movl	$93, %esi	#,
+	call	seq_putc	#
 	addq	$16, %rsp	#,
 	popq	%rbx	#
 	popq	%r12	#
…


* Is this kind of assembler code comparison useful to clarify relevant
  differences further?

* Are any software development concerns left over for such a transformation?

Regards,
Markus

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Development]     [Kernel Announce]     [Kernel Newbies]     [Linux Networking Development]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Device Mapper]

  Powered by Linux