linux-kernel - Re: [PATCH] printk: Add printk_flush() to force buffered text to console

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Jun 2012 21:30:17 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Fengguang Wu <fengguang.wu@...el.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"kay.sievers" <kay.sievers@...y.org>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] printk: Add printk_flush() to force buffered text to
 console

On Fri, Jun 15, 2012 at 12:22:33PM +0800, Fengguang Wu wrote:
> > I actually would like to make these more compact. As all my test box
> > consoles go through serial ports, just booting through this takes more
> > time the the compile itself.
> 
> The tests took 23 seconds boot time on one kernel:
> 
>         [    0.152934] Testing tracer nop: PASSED
>         ...1577 lines total...
>         [   23.206550] Testing kprobe tracing: OK
> 
> And 135 seconds in another bloated kernel:
> 
>         [  115.396441] Testing event 9p_client_req: OK
>         ...2545 lines total...
>         [  240.268783] Testing kprobe tracing: OK
> 
> I'd appreciate if the boot time can be reduced. Because I'm doing
> kernel boot tests for *every single* commits.
> 
> It may look insane amount of work, but it's still manageable: with 10
> kvm instances each take 1 minute to boot test a kernel, I can boot
> test 60*24*10=14400 kernels in one day. That's a rather big number.
> That allows me to run more cpu/vm/io stress tests for each kernel :-)

Do you really want to enable those tests for your test kernels?  Can
they fail if we mess up other parts of the kernel, or do they only test
the tracing portions?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/