* Colton Lewis wrote:
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -6915,6 +6915,16 @@ void perf_unregister_guest_info_callbacks(struct
> perf_guest_info_callbacks *cbs)
> EXPORT_SYMBOL_GPL(perf_unregister_guest_info_callbacks);
> #endif
>
> +unsigned long perf_misc_flags
* Colton Lewis wrote:
> Break the assignment logic for misc flags into their own respective
> functions to reduce the complexity of the nested logic.
>
> Signed-off-by: Colton Lewis
> ---
> arch/x86/events/core.c| 31 +++
> arch/x86/include/asm/perf_ev
* Mike Rapoport wrote:
> +/**
> + * enum execmem_type - types of executable memory ranges
> + *
> + * There are several subsystems that allocate executable memory.
> + * Architectures define different restrictions on placement,
> + * permissions, alignment and other parameters for memory that c
* Mike Rapoport wrote:
> for (s = start; s < end; s++) {
> void *addr = (void *)s + *s;
> + void *wr_addr = addr + module_writable_offset(mod, addr);
So instead of repeating this pattern in a dozen of places, why not use a
simpler method:
void
* Rohan McLure wrote:
> Rohan McLure (11):
> Revert "mm/page_table_check: remove unused parameter in
> [__]page_table_check_pud_set"
> Revert "mm/page_table_check: remove unused parameter in
> [__]page_table_check_pmd_set"
> Revert "mm/page_table_check: remove unused parameter in
> [__
the title as well, something like:
arch/x86: Remove now superfluous sentinel elem from ctl_table arrays
With that propagated into the whole series:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
* Peter Zijlstra wrote:
> On Wed, May 24, 2023 at 03:44:59PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the tip tree, today's linux-next build (powerpc
> > pseries_le_defconfig) failed to boot like this:
> >
> > Built 1 zonelists, mobility grouping on. Total pages: 327
* Michal Hocko wrote:
> On Tue 10-01-23 16:44:42, Suren Baghdasaryan wrote:
> > On Tue, Jan 10, 2023 at 4:39 PM Davidlohr Bueso wrote:
> > >
> > > On Mon, 09 Jan 2023, Suren Baghdasaryan wrote:
> > >
> > > >This configuration variable will be used to build the support for VMA
> > > >locking du
* Sathvika Vasireddy wrote:
> Hi Ingo, Happy New Year!
Happy New Year to you too! :-)
> On 07/01/23 15:51, Ingo Molnar wrote:
> > * Sathvika Vasireddy wrote:
> >
> > > Currently, decode_instructions() is failing if it is not able to find
> > > inst
ny IPI sent via __smp_call_single_queue(),
> which covers __ttwu_queue_wakelist() and irq_work_queue_on() "for free".
>
> Signed-off-by: Valentin Schneider
> Reviewed-by: Steven Rostedt (Google)
Acked-by: Ingo Molnar
Patch series logistics:
- No objections from the scheduler s
* Sathvika Vasireddy wrote:
> Currently, decode_instructions() is failing if it is not able to find
> instruction, and this is happening since commit dbcdbdfdf137b4
> ("objtool: Rework instruction -> symbol mapping") because it is
> expecting instruction for STT_NOTYPE symbols.
>
> Due to this
it needs:
>
> Before: 650.980 ms (+-1.94%)
> After: 569.396 ms (+-1.38%)
Nice!
> arch/x86/mm/fault.c | 4
Reviewed-by: Ingo Molnar
Minor comment typo:
> + /*
> + * We should do the same as VM_FAULT_RETRY, but let's not
>
! For the x86 bits:
Acked-by: Ingo Molnar
Thanks,
Ingo
2 +-
> arch/x86/mm/numa.c | 2 +-
> include/linux/memblock.h | 19 ---
> mm/memblock.c | 4 ++--
> mm/page_alloc.c| 8
> 8 files changed, 28 insertions(+), 14 deletions(-)
The x86 part:
Acked-by: Ingo Molnar
Thanks,
Ingo
om limited range will anyway fail if there is no enough
> memory, so there is no need for extra traversal of memblock.memory
>
> Signed-off-by: Mike Rapoport
Assuming that this got or will get tested with a crash kernel:
Acked-by: Ingo Molnar
Thanks,
Ingo
>
> Signed-off-by: Mike Rapoport
Assuming there's no hidden dependency here breaking something:
Acked-by: Ingo Molnar
Thanks,
Ingo
* Mike Rapoport wrote:
> On Tue, Jul 28, 2020 at 12:44:40PM +0200, Ingo Molnar wrote:
> >
> > * Mike Rapoport wrote:
> >
> > > From: Mike Rapoport
> > >
> > > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> >
ons(-)
I suspect you'd like to carry this in the -mm tree?
Acked-by: Ingo Molnar
Thanks,
Ingo
* pet...@infradead.org wrote:
>
> Prior to commit 859d069ee1dd ("lockdep: Prepare for NMI IRQ state
> tracking") IRQ state tracking was disabled in NMIs due to nmi_enter()
> doing lockdep_off() -- with the obvious requirement that NMI entry
> call nmi_enter() before trace_hardirqs_off().
>
>
mal, and DEBUG_VM increases size anyway.
Other than that this looks good to me:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
* Kirill A. Shutemov wrote:
> On Mon, Oct 07, 2019 at 03:06:17PM +0200, Ingo Molnar wrote:
> >
> > * Anshuman Khandual wrote:
> >
> > > This adds a test module which will validate architecture page table
> > > helpers
> > > and accessor
* Anshuman Khandual wrote:
> This adds a test module which will validate architecture page table helpers
> and accessors regarding compliance with generic MM semantics expectations.
> This will help various architectures in validating changes to the existing
> page table helpers or addition of
* Linus Torvalds wrote:
> On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski wrote:
> >
> > Linus, you rejected resolveat() because you wanted a *nice* API
>
> No. I rejected resoveat() because it was a completely broken garbage
> API that couldn't do even basic stuff right (like O_CREAT).
>
>
* Qian Cai wrote:
> I thought about making it a bool in the first place, but since all
> other similar helpers (arch_is_kernel_initmem_freed(),
> arch_is_kernel_text(), arch_is_kernel_data() etc) could be bool too but
> are not, I kept arch_is_bss_hole() just to be “int” for consistent.
>
>
* Qian Cai wrote:
> The commit 108c14858b9e ("locking/lockdep: Add support for dynamic
> keys") introduced a boot warning on powerpc below, because since the
> commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds
> kvm_tmp[] into the .bss section and then free the rest of unused s
* Peter Zijlstra wrote:
> On Mon, Sep 02, 2019 at 08:25:24PM +0800, Yunsheng Lin wrote:
> > On 2019/9/2 15:25, Peter Zijlstra wrote:
> > > On Mon, Sep 02, 2019 at 01:46:51PM +0800, Yunsheng Lin wrote:
> > >> On 2019/9/1 0:12, Peter Zijlstra wrote:
> > >
> > >>> 1) because even it is not set, t
WARNING
> "cpumask_of_node(%d): node > nr_node_ids(%u)\n",
> node, nr_node_ids);
Nitpicking: please also fix the kernel message to say ">=".
With that:
Acked-by: Ingo Molnar
Note that:
- arch/arm64/mm/numa.c copied the sa
* Dave Hansen wrote:
> Reported-by: Richard Biener
> Reported-by: H.J. Lu
> Fixes: dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap")
> Cc: Yang Shi
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Cc: Andy Lutomirski
> Cc: x...@kernel.org
> Cc: Andrew Morton
> Cc: linux-ker...@
* Rasmus Villemoes wrote:
> I _am_ bending the C rules a bit with the "extern some_var; asm
> volatile(".section some_section\nsome_var: blabla");". I should
> probably ask on the gcc list whether this way of defining a local
> symbol in inline assembly and referring to it from C is supposed
* Rasmus Villemoes wrote:
> On 09/04/2019 23.25, Rasmus Villemoes wrote:
>
> > While refreshing these patches, which were orignally just targeted at
> > x86-64, it occured to me that despite the implementation relying on
> > inline asm, there's nothing x86 specific about it, and indeed it seem
l;
> +}
> +
> +static inline unsigned long frame_pointer(struct pt_regs *regs)
> +{
> + return regs->bp;
> +}
>
> -#include
> +static inline unsigned long user_stack_pointer(struct pt_regs *regs)
> +{
> + return regs->sp;
> +}
> +
> +stati
* Masahiro Yamada wrote:
> Commit 60a3cdd06394 ("x86: add optimized inlining") introduced
> CONFIG_OPTIMIZE_INLINING, but it has been available only for x86.
>
> The idea is obviously arch-agnostic although we need some code fixups.
> This commit moves the config entry from arch/x86/Kconfig.de
* Waiman Long wrote:
> I looked at the assembly code in arch/x86/include/asm/rwsem.h. For both
> trylocks (read & write), the count is read first before attempting to
> lock it. We did the same for all trylock functions in other locks.
> Depending on how the trylock is used and how contended th
* Michal Hocko wrote:
> On Thu 24-01-19 11:10:50, Dave Hansen wrote:
> > On 1/24/19 6:17 AM, Michal Hocko wrote:
> > > and nr_cpus set to 4. The underlying reason is tha the device is bound
> > > to node 2 which doesn't have any memory and init_cpu_to_node only
> > > initializes memory-less nod
* Will Deacon wrote:
> On Mon, Feb 11, 2019 at 11:39:27AM +0100, Ingo Molnar wrote:
> >
> > * Ingo Molnar wrote:
> >
> > > Sounds good to me - I've merged this patch, will push it out after
> > > testing.
> >
> > Based on Peter&
* Ingo Molnar wrote:
> Sounds good to me - I've merged this patch, will push it out after
> testing.
Based on Peter's feedback I'm delaying this - performance testing on at
least one key ll/sc arch would be nice indeed.
Thanks,
Ingo
* Waiman Long wrote:
> On 02/07/2019 02:51 PM, Davidlohr Bueso wrote:
> > On Thu, 07 Feb 2019, Waiman Long wrote:
> >> 30 files changed, 1197 insertions(+), 1594 deletions(-)
> >
> > Performance numbers on numerous workloads, pretty please.
> >
> > I'll go and throw this at my mmap_sem intensiv
* Waiman Long wrote:
> On 02/10/2019 09:00 PM, Waiman Long wrote:
> > As the generic rwsem-xadd code is using the appropriate acquire and
> > release versions of the atomic operations, the arch specific rwsem.h
> > files will not be that much faster than the generic code as long as the
> > atom
boot/header.S| 8 +++-
> arch/x86/include/asm/boot.h | 6 --
> 6 files changed, 23 insertions(+), 7 deletions(-)
Acked-by: Ingo Molnar
> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> index 4c881c850125..af2efb256527 100644
> --- a/arch/x
; KBUILD_CFLAGS += $(cflags-y)
>
> else
> @@ -50,6 +47,4 @@ ELF_FORMAT := elf64-x86-64
> LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib64
> LINK-y += -m64
>
> -# Do unit-at-a-time unconditionally on x86_64, following the host
> -KBUILD_CFLAGS += $(call cc-option,-funit-at-a-time)
> endif
Acked-by: Ingo Molnar
Thanks,
Ingo
arch/x86/include/asm/hugetlb.h | 69 --
> include/asm-generic/hugetlb.h| 88
> +++-
> 15 files changed, 135 insertions(+), 394 deletions(-)
The x86 bits look good to me (assuming it's all tested on all relevant
architectures, etc.)
Acked-by: Ingo Molnar
Thanks,
Ingo
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, contains a recently merged
> tip/perf/urgent,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit c2586cfbb905939b79b49a9121fb0a59a5668fd6:
>
> Merge re
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, just to get the build without warnings
> and finishing successfully in all my test environments,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 7f635f
* Peter Zijlstra wrote:
> On Mon, Jul 09, 2018 at 11:40:14PM +0530, Abdul Haleem wrote:
>
> > Thanks Peter for the patch, build and boot is fine.
> >
> > Reported-and-tested-by: Abdul Haleem
>
> Excellent, Ingo can you stick this in?
Sure, done!
Thanks,
Ingo
may
> apparently get confused by an input section called .discard without
> any suffixes, this series is good to go, but requires your ack to
> proceed, so I would like to ask you to share your comments and/or
> objections. Also, any suggestions or recommendations regarding the
> route these patches should take are highly appreciated.
LGTM:
Acked-by: Ingo Molnar
Regarding route - I suspect -mm would be good, or any other tree that does a
lot
of cross-arch testing?
Thanks,
Ingo
* Shea Levy wrote:
> > Please also put it into Documentation/features/.
>
> I switched this patch series (the latest revision v6 was just posted) to
> using weak symbols instead of Kconfig. Does it still warrant documentation?
Probably not.
Thanks,
Ingo
* Shea Levy wrote:
> Now only those architectures that have custom initrd free requirements
> need to define free_initrd_mem.
>
> Signed-off-by: Shea Levy
Please put the Kconfig symbol name this patch introduces both into the title,
so
that people know what to grep for.
> ---
> arch/alpha
* John Paul Adrian Glaubitz wrote:
> On 03/27/2018 12:40 PM, Linus Torvalds wrote:
> > On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz
> > wrote:
> >>
> >> What about a tarball with a minimal Debian x32 chroot? Then you can
> >> install interesting packages you would like to test you
* Al Viro wrote:
> > For example this attempt at creating a new system call:
> >
> > SYSCALL_DEFINE3(moron, int, fd, loff_t, offset, size_t, count)
> >
> > ... would translate into something like:
> >
> > .name = "moron", .pattern = "WWW", .type = "int",.size = 4,
> > .name = NU
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, this has those 31 patches that were
> blocked due to some problems (author not being the fist S-o-B, build
> broken on ppc), those issues should all be fixed and then we have 14
> patches more, described in the sign
* Al Viro wrote:
> On Sun, Mar 18, 2018 at 06:18:48PM +, Al Viro wrote:
>
> > I'd done some digging in that area, will find the notes and post.
>
> OK, found:
Very nice writeup - IMHO this should go into Documentation/!
> OTOH, consider arm. There we have
> * r0, r1, r2, r3, [sp,#
Tested on powerpc and x86_64.
>
> cc: Dave Hansen
> cc: Michael Ellermen
> cc: Ingo Molnar
> Signed-off-by: Ram Pai
> ---
> arch/powerpc/include/asm/pkeys.h | 19 ++-
> arch/x86/include/asm/pkeys.h | 5 +++--
> 2 files changed, 17 insertions(+
(-)
> create mode 100644 tools/testing/selftests/vm/pkey-helpers.h
> create mode 100644 tools/testing/selftests/vm/protection_keys.c
> delete mode 100644 tools/testing/selftests/x86/pkey-helpers.h
> delete mode 100644 tools/testing/selftests/x86/protection_keys.c
Acked-by: Ingo Molnar
Thanks,
Ingo
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, this is on top of tip/perf/urgent.
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 297f9233b53a08fd457815e19f1d6f2c3389857b:
>
> kprobes: Propagate e
> header files).
>
> Signed-off-by: Randy Dunlap
Nice find:
Reviewed-by: Ingo Molnar
I agree that it needs to go through 0-day to find any hidden dependencies we
might
have grown due to this.
Thanks,
Ingo
* Mathieu Desnoyers wrote:
>
> +config ARCH_HAS_MEMBARRIER_HOOKS
> + bool
Yeah, so I have renamed this to ARCH_HAS_MEMBARRIER_CALLBACKS, and propagated
it
through the rest of the patches. "Callback" is the canonical name, and I also
cringe every time I see 'hook'.
Please let me know i
el.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next&id=92e3da3cf193fd27996909956c12a23c0333da44
All three patches look sane to me. If you would like to carry these generic
bits
in the PowerPC tree as well then:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
* Ard Biesheuvel wrote:
> Annoyingly, we need this because there is a single instance of a
> special section that ends up in the EFI stub code: we build lib/sort.c
> again as a EFI libstub object, and given that sort() is exported, we
> end up with a ksymtab section in the EFI stub. The sort() t
/sparc/include/asm/pci_32.h |2 --
> arch/x86/include/asm/pci.h |2 --
> arch/xtensa/include/asm/pci.h |2 --
> 15 files changed, 10 insertions(+), 62 deletions(-)
Nice cleanups! For the whole series:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 1b2f76d77a277bb70d38ad0991ed7f16bbc115a9:
>
> Merge tag 'perf-core-for-mingo-4.14-20170829' of
> git
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
>
> The following changes since commit 82119cbe8e1e32cc2a941393e59816e731681310:
>
> Merge tag 'perf-core-for-mingo-4.14-20170801' of
>
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 007b811b4041989ec2dc91b9614aa2c41332723e:
>
> Merge tag 'perf-core-for-mingo-4.13-20170719' of
> git
nel.org
> Signed-off-by: Oliver O'Halloran
Acked-by: Ingo Molnar
Thanks,
Ingo
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit ffa86c2f1a8862cf58c873f6f14d4b2c3250fb48:
>
> Merge tag 'perf-core-for-mingo-4.12-20170314' of
> git
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 84e5b549214f2160c12318aac549de85f600c79a:
>
> Merge tag 'perf-core-for-mingo-4.11-20170306' of
> git
| 6 +
> arch/x86/kernel/stacktrace.c | 96 +++-
> arch/x86/kernel/unwind_frame.c | 2 +
for the x86 and scheduler changes:
Acked-by: Ingo Molnar
Thanks,
Ingo
* Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 9d020d33fc1b2faa0eb35859df1381ca5dc94ffe:
>
> Merge branch 'linu
& 3 via the powerpc tree for v4.11.
Acked-by: Ingo Molnar
Thanks,
Ingo
* Paul E. McKenney wrote:
> On Sun, Jan 15, 2017 at 10:40:58AM +0100, Ingo Molnar wrote:
> >
> > * Paul E. McKenney wrote:
> >
> > > > [sounds of rummaging around in the Git tree]
> > > >
> > > > I found this commit of
* Paul E. McKenney wrote:
> > [sounds of rummaging around in the Git tree]
> >
> > I found this commit of yours from ancient history (more than a year ago!):
> >
> > commit 12d560f4ea87030667438a169912380be00cea4b
> > Author: Paul E. McKenney
> > Date: Tue Jul 14 18:35:23 2015 -0700
>
* Paul E. McKenney wrote:
> On Sun, Jan 15, 2017 at 08:11:23AM +0100, Ingo Molnar wrote:
> >
> > * Paul E. McKenney wrote:
> >
> > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > index 357b32aaea48..5fdfe874229e 100644
> >
* Paul E. McKenney wrote:
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 357b32aaea48..5fdfe874229e 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -1175,11 +1175,11 @@ do { \
> * if the UNLOCK and LOCK are executed by the same CPU or i
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, I had most of this queued before your first
> pull req to Linus for 4.10, most are fixes, with 'perf sched timehist --idle'
> as a followup new feature to the 'perf sched timehist' command introduced in
> this win
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit e7af7b15121ca08c31a0ab9df71a41b4c53365b4:
>
> Merge tag 'perf-core-for-mingo-20161201' of
> git://gi
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> Build and test stats at the end of the message.
>
> The following changes since commit 41aad2a6d4fcdda8d73c9739daf7a9f3f49499d6:
>
> Merge tag 'perf-core-for-mingo-20160929' of
> git://git.k
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, more to come soon,
>
> - Arnaldo
>
> Build and test results at the end of this message.
>
> The following changes since commit 6b652de2b27c0a4020ce0e8f277e782b6af76096:
>
> Merge tag 'perf-core-for-mingo-20160
;> > so, if you're ok with the layout, how do you want to proceed further?
> >>
> >> If the split version is acceptable it's fine for me to merge it.
> >>
> >> I'll add split-json to my scripting, so the next update would
> >> be split too.
> >
> > ook, I'll wait for patches then
>
> Who are you waiting for patches from?
>
> Would be great if this could go in for 4.9 still.
No objections from me - the latest bits were good:
Acked-by: Ingo Molnar
Thanks,
Ingo
* Anton Blanchard wrote:
> Hi Anna-Maria,
>
> > >> Install the callbacks via the state machine and let the core invoke
> > >> the callbacks on the already online CPUs.
> > >
> > > This is causing an oops on ppc64le QEMU, looks like a NULL
> > > pointer:
> >
> > Did you tested it against ti
* PaX Team wrote:
> On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
>
> > I like the series, but I have one minor nit to pick. The effect of this
> > series is to harden usercopy, but most of the code is really about
> > infrastructure to validate that a pointed-to object is valid.
>
> actua
* Rik van Riel wrote:
> On Fri, 2016-07-08 at 19:22 -0700, Laura Abbott wrote:
> >
> > Even with the SLUB fixup I'm still seeing this blow up on my arm64
> > system. This is a
> > Fedora rawhide kernel + the patches
> >
> > [0.666700] usercopy: kernel memory exposure attempt detected from
* Linus Torvalds wrote:
> On Fri, Jul 8, 2016 at 1:46 AM, Ingo Molnar wrote:
> >
> > Could you please try to find some syscall workload that does many small user
> > copies and thus excercises this code path aggressively?
>
> Any stat()-heavy path will hit cp_new
* Kees Cook wrote:
> - I couldn't detect a measurable performance change with these features
> enabled. Kernel build times were unchanged, hackbench was unchanged,
> etc. I think we could flip this to "on by default" at some point.
Could you please try to find some syscall workload that doe
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
>
> The following changes since commit 1b6de5917172967acd8db4d222df4225d23a8a60:
>
> perf/x86/intel/pt: Convert ACCESS_ONCE()s (2016-05-05 10:16:29 +0200)
>
> are available in the git reposito
* Andy Lutomirski wrote:
> > Another idea to detect missing frames: for each return address on the
> > stack,
> > ensure there's a corresponding "call " instruction immediately
> > preceding
> > the return location, where matches what's on the stack.
>
> Hmm, interesting.
>
> I hope your
* Michael Ellerman wrote:
> On Wed, 2016-04-13 at 09:43 +0200, Ingo Molnar wrote:
> > * Srikar Dronamraju wrote:
> >
> > > * Anton Blanchard [2016-04-06 21:59:50]:
> > >
> > > > Looks good, and the patch below doe
* Srikar Dronamraju wrote:
> * Anton Blanchard [2016-04-06 21:59:50]:
>
> > Looks good, and the patch below does fix the oops for me.
> >
> > Anton
> > --
> >
> > task_pt_regs() can return NULL for kernel threads, so add a check.
> > This fixes an oops at boot on ppc64.
> >
> > Signed-off-b
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit f6343be96ebbae38a07e0878810f5bbc0c38cade:
>
> Merge tag 'perf-urgent-for-mingo-20160329' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into
* David Long wrote:
> On 02/09/2016 04:45 AM, Ingo Molnar wrote:
> >
> >* Michael Ellerman wrote:
> >
> >>On Tue, 2016-02-09 at 00:38 -0500, David Long wrote:
> >>
> >>>From: "David A. Long"
> >>>
> >>>M
* Michael Ellerman wrote:
> On Tue, 2016-02-09 at 00:38 -0500, David Long wrote:
>
> > From: "David A. Long"
> >
> > Move duplicate and functionally equivalent code for accessing registers
> > and stack (CONFIG_HAVE_REGS_AND_STACK_ACCESS_API) from arch subdirs into
> > common kernel files.
> >
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> This is on top of the previously submitted perf-core-for-mingo tag,
> please consider applying,
>
> - Arnaldo
>
> The following changes since commit 5ac76283b32b116c58e362e99542182ddcfc8262:
>
> perf cpumap: Auto initialize cpu__max_{n
* Ard Biesheuvel wrote:
> This implements text-relative kallsyms address tables. This was developed as
> part of my series to implement KASLR/CONFIG_RELOCATABLE for arm64, but I
> think
> it may be beneficial to other architectures as well, so I am presenting it as
> a
> separate series.
>
* Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit 097f70b3c4d84ffccca15195bdfde3a37c0a7c0f:
>
> Merge branch 'upstream' of
> git://git.linux-mips.org/pub/scm/ralf/upstre
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit 9c17dbc6eb73bdd8a6aaea1baefd37ff78d86148:
>
> Merge tag 'perf-core-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
* Kevin Hao wrote:
> Hi,
>
> v2:
> Drop the following two patches as suggested by Ingo and Peter:
> jump_label: no need to acquire the jump_label_mutex in jump_lable_init()
> jump_label: introduce DEFINE_STATIC_KEY_{TRUE,FALSE}_ARRAY macros
>
> v1:
> I have tried to change the {cpu,mmu
* Kevin Hao wrote:
> On Fri, Aug 21, 2015 at 08:28:26AM +0200, Ingo Molnar wrote:
> >
> > * Kevin Hao wrote:
> >
> > > These are used to define a static_key_{true,false} array.
> > >
> > > Signed-off-by: Kevin Hao
> > > ---
> >
* Kevin Hao wrote:
> These are used to define a static_key_{true,false} array.
>
> Signed-off-by: Kevin Hao
> ---
> include/linux/jump_label.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index 7f653e8f6690..5c1d6a49
* Andrew Morton wrote:
> On Tue, 18 Aug 2015 07:38:25 +0200 Christoph Hellwig wrote:
>
> > On Mon, Aug 17, 2015 at 02:24:29PM -0700, Andrew Morton wrote:
> > > 110254 bytes saved, shrinking the kernel by a whopping 0.17%.
> > > Thoughts?
> >
> > Sounds fine to me.
>
> OK, I'll clean it up a
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit a9a3cd900fbbcbf837d65653105e7bfc583ced09:
>
> Merge tag 'perf-core-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
* Andi Kleen wrote:
> > So instead of this flat structure, there should at minimum be broad
> > categorization
> > of the various parts of the hardware they relate to: whether they relate to
> > the
> > branch predictor, memory caches, TLB caches, memory ops, offcore, decoders,
> > executio
* Ingo Molnar wrote:
>
> * Jiri Olsa wrote:
>
> > On Wed, May 27, 2015 at 11:59:04PM +0900, Namhyung Kim wrote:
> > > Hi Andi,
> > >
> > > On Wed, May 27, 2015 at 11:40 PM, Andi Kleen wrote:
> > > >> So we build tables of all mod
1 - 100 of 363 matches
Mail list logo
