[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YBqtZwIbj6kQEiEd@hirez.programming.kicks-ass.net>
Date: Wed, 3 Feb 2021 15:04:23 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Frederic Weisbecker <frederic@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Paul E . McKenney" <paulmck@...nel.org>,
Ingo Molnar <mingo@...hat.com>, Michal Hocko <mhocko@...e.com>,
rostedt@...dmis.org, jbaron@...mai.com, ardb@...nel.org
Subject: Re: [RFC PATCH 6/8] preempt/dynamic: Provide
preempt_schedule[_notrace]() static calls
On Wed, Jan 27, 2021 at 05:18:37PM -0600, Josh Poimboeuf wrote:
> On Wed, Jan 27, 2021 at 01:02:18PM -0600, Josh Poimboeuf wrote:
> > On Wed, Jan 27, 2021 at 01:00:07PM -0600, Josh Poimboeuf wrote:
> > > On Wed, Jan 27, 2021 at 07:44:01PM +0100, Peter Zijlstra wrote:
> > > > On Wed, Jan 27, 2021 at 10:33:08AM -0600, Josh Poimboeuf wrote:
> > > >
> > > > > What did you think about .static_call_tramp_key? I could whip up a
> > > > > patch later unless you beat me to it.
> > > >
> > > > Yeah, I'm not sure.. why duplicate information already present in
> > > > kallsyms?
> > >
> > > Well, but it's not exactly duplicating kallsyms. No need to store
> > > symbol names, just the pointer relationships. And kallsyms is
> > > presumably slow.
> > >
> > > > There's a fair number of features that already require KALLSYMS, I can't
> > > > really be bothered about adding one more (kprobes, function_tracer,
> > > > stack_tracer, ftrace_syscalls).
>
> Here ya go. It builds... And the tramp_key section is nice and small.
>
> Relocation section [1497] '.rela.static_call_tramp_key' for section [1496] '.static_call_tramp_key' at offset 0x179ab818 contains 8 entries:
> Offset Type Value Addend Name
> 000000000000000000 X86_64_PC32 0x00000000000004c0 +0 __SCT__preempt_schedule
> 0x0000000000000004 X86_64_PC32 0x000000000005ee10 +0 __SCK__preempt_schedule
> 0x0000000000000008 X86_64_PC32 0x00000000000004c8 +0 __SCT__preempt_schedule_notrace
> 0x000000000000000c X86_64_PC32 0x000000000005ee00 +0 __SCK__preempt_schedule_notrace
> 0x0000000000000010 X86_64_PC32 0x00000000000004d0 +0 __SCT__cond_resched
> 0x0000000000000014 X86_64_PC32 0x000000000005dd20 +0 __SCK__cond_resched
> 0x0000000000000018 X86_64_PC32 0x00000000000004d8 +0 __SCT__might_resched
> 0x000000000000001c X86_64_PC32 0x000000000005dd10 +0 __SCK__might_resched
>
Fair enough I suppose. I'll slap a changelog and your SoB on it and I
suppose I'll got commit the whole lot. Then we can forget about it
again.
Powered by blists - more mailing lists