at 2:31 AM, Ingo Molnar wrote:
>
> * Nadav Amit wrote:
>
>>> Are you using defconfig or a reasonable distro-config for your tests?
>>
>> I think it is best to take the kernel and run localyesconfig for testing.
>
> Ok, agreed - and this makes the numbers you provided pretty representative.
>
On 2018-10-04 21:33, H. Peter Anvin wrote:
> Here is the horrible code I mentioned yesterday. This is about
> implementing the immediate-patching framework that Linus and others have
> discussed (it helps both performance and kernel hardening):
Heh, I did a POC in userspace some years ago for lo
* Borislav Petkov wrote:
> On Fri, Oct 05, 2018 at 11:31:08AM +0200, Ingo Molnar wrote:
> >
> > * Nadav Amit wrote:
> >
> > > > Are you using defconfig or a reasonable distro-config for your tests?
> > >
> > > I think it is best to take the kernel and run localyesconfig for testing.
> >
>
On Fri, Oct 05, 2018 at 11:31:08AM +0200, Ingo Molnar wrote:
>
> * Nadav Amit wrote:
>
> > > Are you using defconfig or a reasonable distro-config for your tests?
> >
> > I think it is best to take the kernel and run localyesconfig for testing.
>
> Ok, agreed - and this makes the numbers you p
* Nadav Amit wrote:
> > Are you using defconfig or a reasonable distro-config for your tests?
>
> I think it is best to take the kernel and run localyesconfig for testing.
Ok, agreed - and this makes the numbers you provided pretty representative.
Good - now that all of my concerns were addr
On 10/04/18 13:29, Andy Lutomirski wrote:
>>
>> Wonderful.
>>
>> Here is the horrible code I mentioned yesterday. This is about
>> implementing the immediate-patching framework that Linus and others have
>> discussed (it helps both performance and kernel hardening):
>>
>
> I'm wondering if a prod
On Thu, Oct 4, 2018 at 12:33 PM H. Peter Anvin wrote:
>
> On 10/04/18 02:16, Ingo Molnar wrote:
> >
> > * h...@zytor.com wrote:
> >
> >> Ingo: I wasn't talking necessarily about the specifics of each bit, but
> >> rather the general
> >> concept about being able to use macros in inlines...
> >
>
On 10/04/18 13:05, Nadav Amit wrote:
>
> Funny. Immediate-patching is what I was playing with when I encountered the
> gcc issue. Performance got worse instead of improving (or at least staying
> the same), because inlining got crazy.
>
> Anyhow, wait for my soon-to-be-sent RFC in which I define
at 12:33 PM, H. Peter Anvin wrote:
> On 10/04/18 02:16, Ingo Molnar wrote:
>> * h...@zytor.com wrote:
>>
>>> Ingo: I wasn't talking necessarily about the specifics of each bit, but
>>> rather the general
>>> concept about being able to use macros in inlines...
>>
>> Ok, agreed about that par
On 10/04/18 02:16, Ingo Molnar wrote:
>
> * h...@zytor.com wrote:
>
>> Ingo: I wasn't talking necessarily about the specifics of each bit, but
>> rather the general
>> concept about being able to use macros in inlines...
>
> Ok, agreed about that part - and some of the patches did improve rea
at 2:45 AM, Ingo Molnar wrote:
>
> * Nadav Amit wrote:
>
>>> Another, separate question I wanted to ask: how do we ensure that the
>>> kernel stays fixed?
>>> I.e. is there some tooling we can use to actually measure whether there's
>>> bad inlining decisions
>>> done, to detect all these b
* Nadav Amit wrote:
> > Another, separate question I wanted to ask: how do we ensure that the
> > kernel stays fixed?
> > I.e. is there some tooling we can use to actually measure whether there's
> > bad inlining decisions
> > done, to detect all these bad patterns that cause bad GCC code ge
at 2:12 AM, Ingo Molnar wrote:
>
> * Nadav Amit wrote:
>
>> I can run some tests. (@hpa: I thought you asked about the -pipe overhead;
>> perhaps I misunderstood).
>
> Well, tests are unlikely to show the overhead of extra lines of this
> magnitude, unless done very carefully, yet the added b
On October 4, 2018 2:12:22 AM PDT, Ingo Molnar wrote:
>
>* Nadav Amit wrote:
>
>> I can run some tests. (@hpa: I thought you asked about the -pipe
>overhead;
>> perhaps I misunderstood).
>
>Well, tests are unlikely to show the overhead of extra lines of this
>magnitude, unless done very carefully
* h...@zytor.com wrote:
> Ingo: I wasn't talking necessarily about the specifics of each bit, but
> rather the general
> concept about being able to use macros in inlines...
Ok, agreed about that part - and some of the patches did improve readability.
Also, the 275 lines macros.s is a lot n
* Nadav Amit wrote:
> I can run some tests. (@hpa: I thought you asked about the -pipe overhead;
> perhaps I misunderstood).
Well, tests are unlikely to show the overhead of extra lines of this
magnitude, unless done very carefully, yet the added bloat exists and is not
even
mentioned by the
On October 4, 2018 1:56:37 AM PDT, Nadav Amit wrote:
>at 1:40 AM, h...@zytor.com wrote:
>
>> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar
>wrote:
>>> * Ingo Molnar wrote:
>>>
I'm also somewhat annoyed at the fact that this series carries a
>>> boatload
of reviewed-by's and acked-by'
* Nadav Amit wrote:
> Finally, note that it’s not as if the binary always becomes smaller.
> Overall, with the full patch-set it is slightly bigger. But still, that’s
> how it was supposed to be if gcc wasn’t doing things badly.
So what I cited was the changelog for the refcount patch, which a
at 1:40 AM, h...@zytor.com wrote:
> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote:
>> * Ingo Molnar wrote:
>>
>>> I'm also somewhat annoyed at the fact that this series carries a
>> boatload
>>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>>> important to point
* h...@zytor.com wrote:
> It's not just for working around a stupid GCC bug, but it also has a huge
> potential for
> cleaning up the inline asm in general.
Sorry but that's just plain false. For example this patch:
x86: cpufeature: use macros instead of inline assembly
... adds an extr
at 12:57 AM, Ingo Molnar wrote:
>
> * Nadav Amit wrote:
>
>> GCC considers the number of statements in inlined assembly blocks,
>> according to new-lines and semicolons, as an indication to the cost of
>> the block in time and space. This data is distorted by the kernel code,
>> which puts inf
On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote:
>
>* Ingo Molnar wrote:
>
>> I'm also somewhat annoyed at the fact that this series carries a
>boatload
>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>> important to point out the large chasm that is gaping between
>
* Ingo Molnar wrote:
> I'm also somewhat annoyed at the fact that this series carries a boatload
> of reviewed-by's and acked-by's, yet none of those reviewers found it
> important to point out the large chasm that is gaping between description
> and reality.
Another problem I just realized is
* Nadav Amit wrote:
> GCC considers the number of statements in inlined assembly blocks,
> according to new-lines and semicolons, as an indication to the cost of
> the block in time and space. This data is distorted by the kernel code,
> which puts information in alternative sections. As a resu
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform inc
25 matches
Mail list logo
