All,
I just noticed this addition to i386 and x86-64, conditionalized upon CONFIG_KPROBES. May I ask what the motivation for
this compatibility breaking change is? Only performance? I consider it already questionable to split out a specific
fault from the general die notification (previous users of the functionality all of the sudden won't get notifications
for one of the most crucial faults anymore), but entirely hiding the functionality (unavailable without CONFIG_KPROBES,
and even with it not getting exported) is really odd.
Thanks for any clarification,
Jan
On Monday 07 August 2006 15:22, Jan Beulich wrote:
> I just noticed this addition to i386 and x86-64, conditionalized upon CONFIG_KPROBES. May I ask what the motivation for
> this compatibility breaking change is?
It's normally policy to only care about in tree code regarding exports and hooks.
But also no policy without exceptions.
> Only performance?
Christopher L. complained about it taking too long on IA64 I think
(but that might have been some IA64 specific quirk)
I think I proposed to use a inline check of the chain and only then
call the external function, but that might not have been implemented
that way.
> I consider it already questionable to split out a specific
> fault from the general die notification (previous users of the functionality all of the sudden won't get notifications
> for one of the most crucial faults anymore), but entirely hiding the functionality (unavailable without CONFIG_KPROBES,
> and even with it not getting exported) is really odd.
You want to use it for your debugger?
-Andi
>> I consider it already questionable to split out a specific
>> fault from the general die notification (previous users of the functionality all of the sudden won't get
notifications
>> for one of the most crucial faults anymore), but entirely hiding the functionality (unavailable without
CONFIG_KPROBES,
>> and even with it not getting exported) is really odd.
>
>You want to use it for your debugger?
Yes, in its "light" form (i.e. without exception handling framework changes) it has to rely on this infrastructure.
Jan
On Monday 07 August 2006 16:50, Jan Beulich wrote:
> >> I consider it already questionable to split out a specific
> >> fault from the general die notification (previous users of the functionality all of the sudden won't get
> notifications
> >> for one of the most crucial faults anymore), but entirely hiding the functionality (unavailable without
> CONFIG_KPROBES,
> >> and even with it not getting exported) is really odd.
> >
> >You want to use it for your debugger?
>
> Yes, in its "light" form (i.e. without exception handling framework changes) it has to rely on this infrastructure.
Ok. I can make it unconditional and export it.
-Andi
"Jan Beulich" (on Mon, 07 Aug 2006 14:22:54 +0100) wrote:
>All,
>
>I just noticed this addition to i386 and x86-64, conditionalized upon CONFIG_KPROBES. May I ask what the motivation for
>this compatibility breaking change is? Only performance? I consider it already questionable to split out a specific
>fault from the general die notification (previous users of the functionality all of the sudden won't get notifications
>for one of the most crucial faults anymore), but entirely hiding the functionality (unavailable without CONFIG_KPROBES,
>and even with it not getting exported) is really odd.
Running all callbacks on the notify_die chain for every page fault was
causing a significant slowdown on large machines, especially when the
callback chain included heartbeat monitors, kernel debuggers and cross
partition NUMA access routines.
Only kprobes needs to know about page faults, none of the other
callbacks care about page faults. So the notify_page_fault_chain chain
was added just for kprobes use, and made conditional on CONFIG_KPROBES.
That way only kprobed systems need to suffer the slowdown in page
faulting.