* Preeti U Murthy wrote:
> It was found when doing a hotplug stress test on POWER, that the machine
> either hit softlockups or rcu_sched stall warnings. The issue was
> traced to commit 7cba160ad789a powernv/cpuidle: Redesign idle states
> management, which exposed the cpu down race with hrtim
* Preeti U Murthy wrote:
> On 04/02/2015 04:12 PM, Ingo Molnar wrote:
> >
> > * Preeti U Murthy wrote:
> >
> >> It was found when doing a hotplug stress test on POWER, that the machine
> >> either hit softlockups or rcu_sched stall warnings. The issue
* Peter Zijlstra wrote:
> On Thu, Apr 02, 2015 at 12:42:27PM +0200, Ingo Molnar wrote:
> > So why not use a suitable CPU_DOWN* notifier for this, instead of open
> > coding it all into a random place in the hotplug machinery?
>
> Because notifiers are crap? ;-) [...]
No
* Sukadev Bhattiprolu wrote:
> This is another attempt to resurrect Andi Kleen's patchset so users
> can specify perf events by their event names rather than raw codes.
>
> This is a rebase of Andi Kleen's patchset from Jul 30, 2014[1] to 4.0.
> (I fixed minor and not so minor conflicts).
So t
* Michael Ellerman wrote:
> On Tue, 2015-04-14 at 10:55 +0200, Ingo Molnar wrote:
> > * Sukadev Bhattiprolu wrote:
> >
> > > This is another attempt to resurrect Andi Kleen's patchset so users
> > > can specify perf events by their event names rather
* Michael Ellerman wrote:
> > We just merged a patch series that was first sent in 2013. Some
> > things take time to get right.
>
> The first attempt to get symbolic event name support into perf was
> sent in 2010, that's FIVE years ago [1].
kgdb took even longer, I think it was first propo
* Hemant Kumar wrote:
> # perf kvm stat report -p 60515
> Analyze events for pid(s) 60515, all VCPUs:
>
>VM-EXITSamples Samples% Time%Min Time Max
> Time Avg time
>
> H_DATA_STORAGE 500635.30% 0.13% 1.94us 49.46us
> 12.3
* Hemant Kumar wrote:
>
> On 05/08/2015 09:58 AM, Ingo Molnar wrote:
> >* Hemant Kumar wrote:
> >
> >> # perf kvm stat report -p 60515
> >>Analyze events for pid(s) 60515, all VCPUs:
> >>
> >>VM-EXITSamples Samples% Time%
* 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 models in the architecture, and choose
> > >> matching one when compiling perf, right? Can't we do that
* 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
* 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
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, I guess the changes are minor of affect just
> some
> non-core feature, so it is you call if you prefer to pull it into perf/urgent
> instead.
>
> Best Regards,
>
> - Arnaldo
>
> The following changes since com
* Anton Blanchard wrote:
> I have a busy ppc64le KVM box where guests sometimes hit the
> infamous "kernel BUG at kernel/smpboot.c:134!" issue during
> boot:
>
> BUG_ON(td->cpu != smp_processor_id());
>
> Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
> output confir
* Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
>
> Warning: if CONFIG_BUG is turned off, and control flow reaches
> a BUG(), the system behaviour will be undefined.
>
> so that people
* Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit c0ffaf3655fab1909a920c8f30ba1722932d01bb:
>
> watchdog: Remove softlockup_thresh from Documentation (2013-05-28 11:28:20
* Peter Zijlstra wrote:
> On Thu, Jul 04, 2013 at 10:52:18PM +1000, Michael Ellerman wrote:
> > I don't think it even needs libpfm4, just some csv files in tools/perf
> > would do the trick.
>
> Right; I think Stephane and Jiri are in favour of creating a 'new'
> project that includes just the
* Michael Ellerman wrote:
> On Tue, Jul 09, 2013 at 10:14:34AM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> > >
> > > So something like they have on ARM?
> > >
> > > vince@pandaboard:/sys/bus/event_source/devices$ ls -l
> > > lrwxrwxrwx 1 roo
* Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Hi Ingo,
>
> Please consider pulling,
>
> Regards,
>
> - Arnaldo
>
> The following changes since commit e5302920da9ef23f9d19d4e9ac85704cc25bee7a:
>
> perf: Fix interrupt handler timing harness (2013-07-05 08:54
* Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Hi Ingo,
>
> Please consider pulling.
>
> There was a long delay in processing patches related to my vacations
> that took longer than antecipated to being addressed.
>
> With the recent acme/perf/urgen
* 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
* 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
the exact hardware interface is
> - strongly in flux, so no good recommendation can be made.
> + initially work for you. As of this writing the exact hardware
> + interface is strongly in flux, so no good recommendation can be
> + m
becomes
> possible to make large mmaps but not small ones.
>
> When an explicit address hint is given, mm/mmap.c's round_hint_to_min()
> will round up to mmap_min_addr.
>
> A topdown search's low_limit should similarly consider mmap_min_addr
> instead of just PAGE_S
* Timothy Pepper wrote:
> On Wed 25 Sep at 09:30:49 +0200 mi...@kernel.org said:
> > > info.flags = VM_UNMAPPED_AREA_TOPDOWN;
> > > info.length = len;
> > > - info.low_limit = PAGE_SIZE;
> > > + info.low_limit = max(PAGE_SIZE, PAGE_ALIGN(mmap_min_addr));
> > > info.high_limit = mm->mmap_ba
* Alexei Starovoitov wrote:
> on x86 system with net.core.bpf_jit_enable = 1
>
> sudo tcpdump -i eth1 'tcp port 22'
>
> causes the warning:
> [ 56.766097] Possible unsafe locking scenario:
> [ 56.766097]
> [ 56.780146]CPU0
> [ 56.786807]
> [ 56.793188] lock(&(&
* Eric Dumazet wrote:
> 1)
> >
> > I took a brief look at arch/x86/net/bpf_jit_comp.c while reviewing this
> > patch.
> >
> > You need to split up bpf_jit_compile(), it's an obscenely large, ~600
> > lines long function. We don't do that in modern, maintainable kernel code.
> >
> > 2)
> >
> > Th
n generation code within the iterator looks good in a
single chunk - splitting it up further than that might in fact make it
less readable.
> > 3)
> >
> > It's nice code altogether! Are there any plans to generalize its
> > interfaces, to allow arbitrary bytec
s.ozlabs.org
> CC: Paul Mundt
> CC: linux...@vger.kernel.org
> CC: "David S. Miller"
> CC: sparcli...@vger.kernel.org
> CC: Guan Xuetao
> CC: Thomas Gleixner
> CC: Ingo Molnar
> CC: "H. Peter Anvin"
> CC: x...@kernel.org
> ---
> drivers/parpo
to do subdir processing
> tools: Honour the O= flag when tool build called from a higher Makefile
> tools: Pass the target in descend
>
> David Sharp (2):
> tracing: Trivial cleanup
> tracing: Reset ring buffer when changing trace_clocks
>
> Feng Tang (1):
&g
Note that I had to do a number of conflict resolutions between
perf/urgent (now upstream) and perf/core, related to UAPI fixes:
commit f0b9abfb044649bc452fb2fb975ff2fd599cc6a3
Merge: adc1ef1 1b3c393
Author: Ingo Molnar
Date: Sat Dec 8 15:25:06 2012 +0100
Merge branch 'linus&
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit 203e04c16330c880538588e932743f404ee4fd66:
>
> Merge tag 'perf-core-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
cessing tracing data
> perf ui browser: Free browser->helpline() on ui_browser__hide()
> perf tests: Call machine__exit in the vmlinux matches kallsyms test
> perf tests: Fix leaks on PERF_RECORD_* test
>
> Borislav Petkov (1):
> tools: Correct typo in to
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit 152fefa921535665f95840c08062844ab2f5593e:
>
> Merge tag 'perf-core-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
e name as a parameter.
>
> Changelog[v2]
> - [Jiri Olsa] No need to define PMU_EVENT_PTR()
>
> Signed-off-by: Sukadev Bhattiprolu
> Acked-by: Jiri Olsa
> Cc: Andi Kleen
> Cc: Anton Blanchard
> Cc: Ingo Molnar
> Cc: Jiri Olsa
> Cc: Paul Mackerras
> Cc: Peter Zij
* Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit cb16b91a449afd01b85ec4e59f30449d11c4acd7:
>
> s390: Fix a header dependencies related build error (2013-03-11 10:43:35
* Madhavan Srinivasan wrote:
> Performance data for different FAULT_AROUND_ORDER values from 4 socket
> Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
> is used to get the stddev values. Test ran in v3.14 kernel (Baseline) and
> v3.15-rc1 for different fault around orde
* Rusty Russell wrote:
> Ingo Molnar writes:
> > * Madhavan Srinivasan wrote:
> >
> >> Performance data for different FAULT_AROUND_ORDER values from 4 socket
> >> Power7 system (128 Threads and 128GB memory). perf stat with repeat of 5
> >> is used t
* Masami Hiramatsu wrote:
> (2014/07/15 16:16), Benjamin Herrenschmidt wrote:
> > On Tue, 2014-07-15 at 13:19 +1000, Michael Ellerman wrote:
> >
> >>> Signed-off-by: Masami Hiramatsu
> >>> Reported-by: Tony Luck
> >>> Tested-by: Tony Luck
> >>> Cc: Michael Ellerman
> >>
> >> Tested-by: Mich
* Masami Hiramatsu wrote:
> Signed-off-by: Masami Hiramatsu
> Signed-off-by: Suzuki K. Poulose
Looks good, but this is not a valid SOB sequence: if Suzuki wrote the
patch then he should be the first SOB (and should have a From line as
well), if he acked it along the way then it should be an
* Masami Hiramatsu wrote:
> (2014/07/16 22:28), Ingo Molnar wrote:
> >
> > * Masami Hiramatsu wrote:
> >
> >> (2014/07/15 16:16), Benjamin Herrenschmidt wrote:
> >>> On Tue, 2014-07-15 at 13:19 +1000, Michael Ellerman wrote:
> >>>
> &
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling,
>
> - Arnaldo
>
> The following changes since commit f373da34282560c60f0c197690eecb1b2dc49fc0:
>
> Merge tag 'perf-core-for-mingo' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
* Paul Gortmaker wrote:
> On Feb 4, 2014 3:52 PM, "Paul Gortmaker"
> wrote:
> >
> > We've had this in linux-next for 2+ weeks (thanks Stephen!) as a
> > linux-stable like queue of patches, and as can be seen here:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/paulg/init.git
>
> Arg
* Stephen Rothwell wrote:
> Hi Ingo,
>
> On Wed, 5 Feb 2014 07:06:33 +0100 Ingo Molnar wrote:
> >
> > So, if you meant Linus to pull it, you probably want to cite a real
> > Git URI along the lines of:
> >
> >git://git.kernel.org/pub/scm/li
* Madhavan Srinivasan wrote:
> Performance data for different FAULT_AROUND_ORDER values from 4 socket
> Power7 system (128 Threads and 128GB memory) is below. Fault around order
> (FAO)
> value of 3 looks more advantageous.
>
> FAULT_AROUND_ORDER Baseline1 3
* Madhavan Srinivasan wrote:
> Performance data for different FAULT_AROUND_ORDER values from 4 socket
> Power7 system (128 Threads and 128GB memory) is below. perf stat with
> repeat of 5 is used to get the stddev values. This patch create
> FAULT_AROUND_ORDER Kconfig parameter and defaults it t
* Ingo Molnar wrote:
> * Madhavan Srinivasan wrote:
>
> > Performance data for different FAULT_AROUND_ORDER values from 4
> > socket Power7 system (128 Threads and 128GB memory) is below. perf
> > stat with repeat of 5 is used to get the stddev values
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> Please consider pulling, it has my latest perf/urgent pull content,
> please let me know if you don't want it to be submitted like that, i.e. if
> you have any problems with my latest perf/urgent pull request and I'll try
> to address it AS
* Peter Zijlstra wrote:
> On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote:
> > arch/powerpc/perf/e6500-events-list.h | 289
> > ++
>
> That's a lot of events to stuff in the kernel, would a
> userspace list not be more convenient?
>
> ISTR there bein
* Jiri Olsa wrote:
> On Mon, Feb 09, 2015 at 11:07:38AM +0100, Ingo Molnar wrote:
> >
> > * Peter Zijlstra wrote:
> >
> > > On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote:
> > > > arch/powe
* Scott Wood wrote:
> On Mon, 2015-02-09 at 21:40 +0100, Andi Kleen wrote:
> > > I'll NAK any external 'download area' (and I told that Andi
> > > before): tools/perf/event-tables/ or so is a good enough
> > > 'download area' with fast enough update cycles.
> >
> > The proposal was to put it
* Anton Blanchard wrote:
> Every now and then I end up with an undebuggable issue
> because multiple CPUs hit something at the same time and
> everything is interleaved:
>
> CR: 4882 XER:
> ,RI
> c003dc72fd10
> ,LE
> d65b84e8
>
* Anton Blanchard wrote:
> +static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
> +static int die_owner = -1;
> +static unsigned int die_nest_count;
> +
> +unsigned long __die_spin_lock_irqsave(void)
> +{
> + unsigned long flags;
> + int cpu;
> +
> + /* racy, but better than
* Ingo Molnar wrote:
>
> * Anton Blanchard wrote:
>
> > +static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
> > +static int die_owner = -1;
> > +static unsigned int die_nest_count;
> > +
> > +unsigned long __die_spin_lock_irqsave(v
* Hector Marco Gisbert wrote:
> +unsigned long randomize_et_dyn(unsigned long base)
> +{
> + unsigned long ret;
> + if ((current->personality & ADDR_NO_RANDOMIZE) ||
> + !(current->flags & PF_RANDOMIZE))
> + return base;
> + ret = base + mmap_rnd();
> + re
ble via the new CONFIG_ARCH_HAS_ELF_RANDOMIZE. For
> these architectures, arch_randomize_brk() is collapsed as
> well.
>
> This is an alternative to the solutions in:
> https://lkml.org/lkml/2015/2/23/442
Nice!
Acked-by: Ingo Molnar
Thanks,
Ingo
__
p_rnd() made available
> via the new CONFIG_ARCH_HAS_ELF_RANDOMIZE. For these architectures,
> arch_randomize_brk() is collapsed as well.
>
> This is an alternative to the solutions in:
> https://lkml.org/lkml/2015/2/23/442
Looks good so far:
Reviewed-by: Ingo Molnar
While revi
* Kees Cook wrote:
> Most architectures don't need to do anything special for the strict
> seccomp syscall entries. Remove the redundant headers and reduce the
> others.
> 19 files changed, 27 insertions(+), 137 deletions(-)
Lovely cleanup factor.
Just to make sure, are you sure the 32-bit d
* Kees Cook wrote:
> On Mon, Mar 2, 2015 at 11:31 PM, Ingo Molnar wrote:
> >
> > * Kees Cook wrote:
> >
> >> To address the "offset2lib" ASLR weakness[1], this separates ET_DYN
> >> ASLR from mmap ASLR, as already done on s390. The architec
he buildbot (so far) seems
> happy with building the rest.
Ok, this looks really good - for all patches:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
nitions were
> identical.
>
> Signed-off-by: Kees Cook
Acked-by: Ingo Molnar
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
* Mel Gorman wrote:
> Dave Chinner reported the following on https://lkml.org/lkml/2015/3/1/226
>
> Across the board the 4.0-rc1 numbers are much slower, and the
> degradation is far worse when using the large memory footprint
> configs. Perf points straight at the cause - this is from 4.0-rc
* Mel Gorman wrote:
> xfsrepair
> 4.0.0-rc1 4.0.0-rc1
> 3.19.0
> vanilla slowscan-v2
> vanilla
> Min real-fsmark1157.41 ( 0.00%) 1150.38 ( 0.61%)
* Mel Gorman wrote:
> Elapsed time is primarily worse on one benchmark -- numa01 which is
> an adverse workload. The user time differences are also dominated by
> that benchmark
>
>4.0.0-rc1 4.0.0-rc1
> 3.19.0
>
* Linus Torvalds wrote:
> On Sat, Mar 7, 2015 at 8:36 AM, Ingo Molnar wrote:
> >
> > And the patch Dave bisected to is a relatively simple patch. Why
> > not simply revert it to see whether that cures much of the
> > problem?
>
> So the problem with that is
* Laurent Dufour wrote:
> Some architecture would like to be triggered when a memory area is moved
> through the mremap system call.
>
> This patch is introducing a new arch_remap mm hook which is placed in the
> path of mremap, and is called before the old area is unmapped (and the
> arch_unma
* Laurent Dufour wrote:
> Some processes (CRIU) are moving the vDSO area using the mremap system
> call. As a consequence the kernel reference to the vDSO base address is
> no more valid and the signal return frame built once the vDSO has been
> moved is not pointing to the new sigreturn address
* Laurent Dufour wrote:
> +static inline void arch_unmap(struct mm_struct *mm,
> + struct vm_area_struct *vma,
> + unsigned long start, unsigned long end)
> +{
> + if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> + mm->c
* Ingo Molnar wrote:
> > +#define __HAVE_ARCH_REMAP
> > +static inline void arch_remap(struct mm_struct *mm,
> > + unsigned long old_start, unsigned long old_end,
> > + unsigned long new_star
* Benjamin Herrenschmidt wrote:
> On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > * Ingo Molnar wrote:
> >
> > > > +#define __HAVE_ARCH_REMAP
> > > > +static inline void arch_remap(struct mm_struct *mm,
> > > > +
* Benjamin Herrenschmidt wrote:
> > > +#define __HAVE_ARCH_REMAP
> > > +static inline void arch_remap(struct mm_struct *mm,
> > > + unsigned long old_start, unsigned long old_end,
> > > + unsigned long new_start, unsigned long new_end)
> > > +{
> > > +
* Laurent Dufour wrote:
> > I argue we should use the right condition to clear vdso_base: if
> > the vDSO gets at least partially unmapped. Otherwise there's
> > little point in the whole patch: either correctly track whether
> > the vDSO is OK, or don't ...
>
> That's a good option, but it
text.vdso_base = new_start;
> + else
> + mm->context.vdso_base = 0;
> + }
> +}
Oh my, that really looks awfully complex, as you predicted, and right
in every mremap() call.
I'm fine with your original, imperfect, KISS approach. Sorry a
* 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
* 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
* 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
* 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
* 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
* 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:
> 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
* 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
* 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
* 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:
> 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
* 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.
> >
* 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
mal, and DEBUG_VM increases size anyway.
Other than that this looks good to me:
Reviewed-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
; 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
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
* 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
* 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
* 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
* 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&
* 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
* 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
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
* 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
* 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
* 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
ant to impact user mode with our change to ll64
> * in the kernel.
> + *
> + * However, some user programs are fine with this. They can
> + * flag __SANE_USERSPACE_TYPES__ to get int-ll64.h here.
> */
> -#if defined(__powerpc64__) && !defined(__KERNEL__)
> +#if !defined(__SAN
1 - 100 of 363 matches
Mail list logo
