Hi Pavel,
On Fri, Mar 10, 2017 at 02:17:51PM +0100, Pavel Machek wrote:
> On Thu 2017-03-09 13:16:09, Geert Uytterhoeven wrote:
> > Hi Pavel,
> >
> > On Thu, Mar 9, 2017 at 11:56 AM, Pavel Machek wrote:
> > > On Thu 2017-03-09 10:38:46, Geert Uytterhoeven wrote:
> > >> On Wed, Mar 8, 2017 at 10:
Hi Pavel,
On Fri, Mar 10, 2017 at 2:17 PM, Pavel Machek wrote:
> On Thu 2017-03-09 13:16:09, Geert Uytterhoeven wrote:
>> On Thu, Mar 9, 2017 at 11:56 AM, Pavel Machek wrote:
>> > On Thu 2017-03-09 10:38:46, Geert Uytterhoeven wrote:
>> >> I hope you do use ccache or distcc?
>> >
>> > I tried to
On Thu 2017-03-09 13:16:09, Geert Uytterhoeven wrote:
> Hi Pavel,
>
> On Thu, Mar 9, 2017 at 11:56 AM, Pavel Machek wrote:
> > On Thu 2017-03-09 10:38:46, Geert Uytterhoeven wrote:
> >> On Wed, Mar 8, 2017 at 10:22 PM, Pavel Machek wrote:
> >> > Well, I have fast CPUs, but most of the time they
On Thu 2017-03-09 16:29:10, Peter Zijlstra wrote:
> On Wed, Mar 08, 2017 at 10:22:53PM +0100, Pavel Machek wrote:
> >
> > Well, I have fast CPUs, but most of the time they just compile
> > stuff. Especially bisect is compile-heavy. I suspect going back to
> > gcc-3.2 would bring me bigger advantag
On Thu, Mar 09, 2017 at 09:14:47AM -0500, Steven Rostedt wrote:
> On Wed, 8 Mar 2017 15:29:59 -0600
> Josh Poimboeuf wrote:
>
> > [adding Steven Rostedt to CC as an FYI]
> >
> > On Wed, Mar 08, 2017 at 10:25:01AM -0800, Linus Torvalds wrote:
> > > On Wed, Mar 8, 2017 at 9:37 AM, Josh Poimboeuf
On Thu, Mar 9, 2017 at 2:49 AM, Pavel Machek wrote:
>
> (On thinkpad X220, compiling bzip2)
You really shouldn't assume that the zlib build tracks the kernel build.
At least at some point, a noticeable part of the build cost for the
kernel was just parsing the fairly big source code. We have hon
On Wed, Mar 08, 2017 at 10:22:53PM +0100, Pavel Machek wrote:
>
> Well, I have fast CPUs, but most of the time they just compile
> stuff. Especially bisect is compile-heavy. I suspect going back to
> gcc-3.2 would bring me bigger advantages than CPU upgrade...
>
But note that 3.2 compiles a dist
On Wed, 8 Mar 2017 15:29:59 -0600
Josh Poimboeuf wrote:
> [adding Steven Rostedt to CC as an FYI]
>
> On Wed, Mar 08, 2017 at 10:25:01AM -0800, Linus Torvalds wrote:
> > On Wed, Mar 8, 2017 at 9:37 AM, Josh Poimboeuf wrote:
> >
> > > - CONFIG_FUNCTION_GRAPH_TRACER sets it on x86-32 because o
Hi Pavel,
On Thu, Mar 9, 2017 at 11:56 AM, Pavel Machek wrote:
> On Thu 2017-03-09 10:38:46, Geert Uytterhoeven wrote:
>> On Wed, Mar 8, 2017 at 10:22 PM, Pavel Machek wrote:
>> > Well, I have fast CPUs, but most of the time they just compile
>> > stuff. Especially bisect is compile-heavy. I sus
On Thu 2017-03-09 10:38:46, Geert Uytterhoeven wrote:
> Hi Pavel,
>
> On Wed, Mar 8, 2017 at 10:22 PM, Pavel Machek wrote:
> > Well, I have fast CPUs, but most of the time they just compile
> > stuff. Especially bisect is compile-heavy. I suspect going back to
> > gcc-3.2 would bring me bigger ad
Hi!
> > > - CONFIG_FUNCTION_GRAPH_TRACER sets it on x86-32 because of a gcc bug
> > > where the stack gets aligned before the mcount call. This issue
> > > should be mostly obsolete as most modern compilers now have -mfentry.
> > > We could make it dependent on CC_USING_FENTRY.
> >
> > Yea
Hi Pavel,
On Wed, Mar 8, 2017 at 10:22 PM, Pavel Machek wrote:
> Well, I have fast CPUs, but most of the time they just compile
> stuff. Especially bisect is compile-heavy. I suspect going back to
> gcc-3.2 would bring me bigger advantages than CPU upgrade...
I hope you do use ccache or distcc?
Hi!
> > - CONFIG_FUNCTION_GRAPH_TRACER sets it on x86-32 because of a gcc bug
> > where the stack gets aligned before the mcount call. This issue
> > should be mostly obsolete as most modern compilers now have -mfentry.
> > We could make it dependent on CC_USING_FENTRY.
>
> Yeah. At some p
[adding Steven Rostedt to CC as an FYI]
On Wed, Mar 08, 2017 at 10:25:01AM -0800, Linus Torvalds wrote:
> On Wed, Mar 8, 2017 at 9:37 AM, Josh Poimboeuf wrote:
> > - CONFIG_FUNCTION_GRAPH_TRACER sets it on x86-32 because of a gcc bug
> > where the stack gets aligned before the mcount call. Thi
On Wed, Mar 8, 2017 at 10:25 AM, Linus Torvalds
wrote:
> On Wed, Mar 8, 2017 at 9:37 AM, Josh Poimboeuf wrote:
> Yeah. At some point we might even upgrade the compiler requirements to
> no longer accept the mcount model.
>
> I think the fentry model is gcc-4.6.0 and up. Currently I guess we
> sup
On Wed, Mar 8, 2017 at 9:37 AM, Josh Poimboeuf wrote:
>
> It does seem to make it bigger. With Pavel's config on gcc 6, if I add
> -maccumulate-outgoing-args:
>
> That's 3.8% more text on x86-32.
That's even more than I expected. I would have expected the
-mregparm=3 to catch so much of our sta
On Tue, Mar 07, 2017 at 10:40:14AM -0800, Linus Torvalds wrote:
> On Tue, Mar 7, 2017 at 10:28 AM, Josh Poimboeuf wrote:
> >
> > Also, the gcc documentation says -maccumulate-outgoing-args is
> > "generally beneficial for performance and size."
>
> Hmm. I wonder how true that is. I'm pretty sure
On Tue, Mar 7, 2017 at 9:38 AM, Josh Poimboeuf wrote:
>
> So I'm thinking we should have -maccumulate-outgoing-args always enabled
> on x86_32 just like we already do on x86_64.
Ugh. I realize we have workarounds for bugs, but I think
-maccumulate-outgoing-args is nasty. It just generates worse c
On Tue, Mar 7, 2017 at 9:52 AM, Linus Torvalds
wrote:
> On Tue, Mar 7, 2017 at 9:38 AM, Josh Poimboeuf wrote:
>>
>> So I'm thinking we should have -maccumulate-outgoing-args always enabled
>> on x86_32 just like we already do on x86_64.
>
> Ugh. I realize we have workarounds for bugs, but I think
On Tue, Mar 7, 2017 at 10:28 AM, Josh Poimboeuf wrote:
>
> Also, the gcc documentation says -maccumulate-outgoing-args is
> "generally beneficial for performance and size."
Hmm. I wonder how true that is. I'm pretty sure it generates bigger
code, although it's probably less noticeable in the kern
On Tue, Mar 07, 2017 at 09:59:44AM -0800, Andy Lutomirski wrote:
> On Tue, Mar 7, 2017 at 9:52 AM, Linus Torvalds
> wrote:
> > On Tue, Mar 7, 2017 at 9:38 AM, Josh Poimboeuf wrote:
> >>
> >> So I'm thinking we should have -maccumulate-outgoing-args always enabled
> >> on x86_32 just like we alrea
On Mon, Mar 06, 2017 at 05:38:07PM +0100, Pavel Machek wrote:
> Sorry for the delay. This is on v4.11-rc1, but that should be similar.
>
> pavel@duo:~$ gcc --version
> gcc (Debian 4.9.2-10) 4.9.2
>
> And here's the disassemble:
>
> c402d200 :
> c402d200: 57 push %edi
On Tue, Mar 07, 2017 at 12:28:55PM -0600, Josh Poimboeuf wrote:
> On Tue, Mar 07, 2017 at 09:59:44AM -0800, Andy Lutomirski wrote:
> > On Tue, Mar 7, 2017 at 9:52 AM, Linus Torvalds
> > wrote:
> > > On Tue, Mar 7, 2017 at 9:38 AM, Josh Poimboeuf
> > > wrote:
> > >>
> > >> So I'm thinking we shou
On Thu 2017-03-02 17:45:14, Josh Poimboeuf wrote:
> On Fri, Feb 24, 2017 at 11:04:39PM -0600, Josh Poimboeuf wrote:
> > On Thu, Feb 23, 2017 at 09:10:39PM +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > >
> > > > > > > Somehow, startup_32_smp() is on the stack twice. The stack
> > > > > > > unwi
On Fri, Feb 24, 2017 at 11:04:39PM -0600, Josh Poimboeuf wrote:
> On Thu, Feb 23, 2017 at 09:10:39PM +0100, Pavel Machek wrote:
> > Hi!
> >
> >
> > > > > > Somehow, startup_32_smp() is on the stack twice. The stack unwind
> > > > > > led
> > > > > > to the startup_32_smp() frame at 0xf50cdf9c r
On Thu, Feb 23, 2017 at 09:10:39PM +0100, Pavel Machek wrote:
> Hi!
>
>
> > > > > Somehow, startup_32_smp() is on the stack twice. The stack unwind led
> > > > > to the startup_32_smp() frame at 0xf50cdf9c rather than the one at
> > > > > 0xf50cdfa8 (which is where it should normally be). So th
Hi!
> > > > Somehow, startup_32_smp() is on the stack twice. The stack unwind led
> > > > to the startup_32_smp() frame at 0xf50cdf9c rather than the one at
> > > > 0xf50cdfa8 (which is where it should normally be). So the question is
> > > > how startup_32_smp() got executed the second time, w
On Wed, Feb 22, 2017 at 04:56:14PM -0600, Josh Poimboeuf wrote:
> On Wed, Feb 22, 2017 at 11:47:55PM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > > > Thinkpad X220, in 32 bit mode... and I'm getting rather scary
> > > > > > messages
> > > > > > from kernel during boot:
> > > > > >
> > > > > >
On Wed, Feb 22, 2017 at 11:47:55PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > > Thinkpad X220, in 32 bit mode... and I'm getting rather scary messages
> > > > > from kernel during boot:
> > > > >
> > > > > Git blame says that message comes from commit
> > > > >
> > > > > commit 24d86f59093b0bcb3
Hi!
> > > > Thinkpad X220, in 32 bit mode... and I'm getting rather scary messages
> > > > from kernel during boot:
> > > >
> > > > Git blame says that message comes from commit
> > > >
> > > > commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb
> > > > Author: Josh Poimboeuf
> > > > Date: Thu Oc
On Wed, Feb 22, 2017 at 10:05:48PM +0100, Pavel Machek wrote:
> Hi!
>
> > > Thinkpad X220, in 32 bit mode... and I'm getting rather scary messages
> > > from kernel during boot:
> > >
> > > Git blame says that message comes from commit
> > >
> > > commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb
On Wed, Feb 22, 2017 at 12:51:11PM -0800, H. Peter Anvin wrote:
> On 02/22/17 08:45, Josh Poimboeuf wrote:
> >>
> >> FWIW, it would be really darned nice to not have all those zeroes in a
> >> 32-bit stack frame dump.
> >
> > Yeah, I'll fix that.
> >
> >> Is not a zero stack frame pointer value a
Hi!
> > Thinkpad X220, in 32 bit mode... and I'm getting rather scary messages
> > from kernel during boot:
> >
> > Git blame says that message comes from commit
> >
> > commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb
> > Author: Josh Poimboeuf
> > Date: Thu Oct 27 08:10:58 2016 -0500
> >
>
On 02/22/17 08:45, Josh Poimboeuf wrote:
>>
>> FWIW, it would be really darned nice to not have all those zeroes in a
>> 32-bit stack frame dump.
>
> Yeah, I'll fix that.
>
>> Is not a zero stack frame pointer value an end of stack token?
>
> There's no end of stack "token" per se, though any fr
On Tue, Feb 21, 2017 at 03:15:36PM -0800, H. Peter Anvin wrote:
> On 02/21/17 15:12, Josh Poimboeuf wrote:
> >>
> >> commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb
> >> Author: Josh Poimboeuf
> >> Date: Thu Oct 27 08:10:58 2016 -0500
> >>
> >> x86/unwind: Ensure stack grows down
> >>
> >>
On 02/21/17 15:12, Josh Poimboeuf wrote:
>>
>> commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb
>> Author: Josh Poimboeuf
>> Date: Thu Oct 27 08:10:58 2016 -0500
>>
>> x86/unwind: Ensure stack grows down
>>
>> Add a sanity check to ensure the stack only grows down, and print
>> a
>>
On Tue, Feb 21, 2017 at 11:14:18PM +0100, Pavel Machek wrote:
> Hi!
>
> Thinkpad X220, in 32 bit mode... and I'm getting rather scary messages
> from kernel during boot:
>
> Git blame says that message comes from commit
>
> commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb
> Author: Josh Poimboeuf
Hi!
Thinkpad X220, in 32 bit mode... and I'm getting rather scary messages
from kernel during boot:
Git blame says that message comes from commit
commit 24d86f59093b0bcb3756cdf47f2db10ff4e90dbb
Author: Josh Poimboeuf
Date: Thu Oct 27 08:10:58 2016 -0500
x86/unwind: Ensure stack grows dow
38 matches
Mail list logo
