n autoconf machinery.
The patch below adds such a script. It detects librt, libpthread and
libnuma. It solves the problem you mention and it removes hardcoded
lib details from the Makefile.
If there's interest for this solution I can finish it and post for
inclusion.
>From 4228140e9dbb7fb
On Tue, 5 Apr 2016 14:18:01 +0800
Yang Zhang wrote:
> On 2016/4/5 5:00, Rik van Riel wrote:
> > On Mon, 2016-04-04 at 16:46 -0400, Luiz Capitulino wrote:
> >> When a vCPU runs on a nohz_full core, the hrtimer used by
> >> the lapic emulation code can be migrated to a
_timer_irqs()
You'll see that apic_timer_fn() will run in core0 while
kvm_inject_apic_timer_irqs() runs in a different core. If
you get both on core0, try running a program that takes 100%
of the CPU and pin it to core0 to force the vCPU out.
Signed-off-by: Luiz Capitulino
---
arch/x86/kvm/lapi
On Thu, 17 Dec 2015 14:46:05 -0800
"Fenghua Yu" wrote:
> Changes in V16:
> - Port to latest upstream kernel
> - Add a spin lock to handle contention when writing closid to MSR and
>creating closid by a user.
Fenghua, Peter, what about all the discussion v15 got
about this interface being j
On Sat, 19 Dec 2015 22:57:30 -0200
Marcelo Tosatti wrote:
> On Sat, Dec 19, 2015 at 11:42:57AM +0100, Thomas Gleixner wrote:
> > On Thu, 17 Dec 2015, Fenghua Yu wrote:
> >
> > > From: Fenghua Yu
> > >
> > > From: Vikas Shivappa
> > >
> > > Add a new cgroup 'intel_rdt' to manage cache allocat
On Thu, 19 Nov 2015 09:35:34 +0100 (CET)
Thomas Gleixner wrote:
> > Well any work on behalf of the important task, should have its cache
> > protected as well (example irq handling threads).
>
> Right, but that's nothing you can do automatically and certainly not
> from a random application.
R
On Wed, 18 Nov 2015 19:25:03 +0100 (CET)
Thomas Gleixner wrote:
> We really need to make this as configurable as possible from userspace
> without imposing random restrictions to it. I played around with it on
> my new intel toy and the restriction to 16 COS ids (that's 8 with CDP
> enabled) make
On Mon, 16 Nov 2015 17:26:57 +0100
Peter Zijlstra wrote:
> On Mon, Nov 16, 2015 at 11:18:42AM -0500, Luiz Capitulino wrote:
> > Peter, I'm giving a serious try on the cgroups patches and would be
> > glad to be enlightened if I'm missing something. But I don't see
On Mon, 16 Nov 2015 10:07:56 +0100
Peter Zijlstra wrote:
> I'm still not seeing what the problem with CAT-cgroup is.
>
> /cgroups/cpuset/
> socket-1/cpus = $socket-1
>tasks = $thread-A
>
> socket-2/cpus = $socket-2
>tasks = $thread-B
>
> /cgroups/cat/
> group-A/bi
On Fri, 13 Nov 2015 14:39:33 -0200
Marcelo Tosatti wrote:
> Attached is an early version of the ioctl based CAT interface we
> have been working on.
We're also writing a user-space app that can manage reservations
from user-space. It's integrated with util-linux. I'll setup a repo
shortly to sha
On Fri, 13 Nov 2015 15:27:40 -0200
Marcelo Tosatti wrote:
> On Fri, Nov 13, 2015 at 05:51:00PM +0100, Peter Zijlstra wrote:
> > On Fri, Nov 13, 2015 at 02:39:33PM -0200, Marcelo Tosatti wrote:
> > > + * * one tcrid entry can be in different locations
> > > + * in different sockets.
On Wed, 4 Nov 2015 16:28:04 +0100 (CET)
Thomas Gleixner wrote:
> On Wed, 4 Nov 2015, Luiz Capitulino wrote:
> > On Wed, 4 Nov 2015 15:57:41 +0100 (CET)
> > Thomas Gleixner wrote:
> >
> > > On Wed, 4 Nov 2015, Luiz Capitulino wrote:
> > >
>
On Wed, 4 Nov 2015 15:57:41 +0100 (CET)
Thomas Gleixner wrote:
> On Wed, 4 Nov 2015, Luiz Capitulino wrote:
>
> > On Thu, 1 Oct 2015 23:09:34 -0700
> > Fenghua Yu wrote:
> >
> > > This series has some preparatory patches and Intel cache allocation
> &g
On Thu, 1 Oct 2015 23:09:39 -0700
Fenghua Yu wrote:
> Adds some data-structures and APIs to support Class of service
> management(closid). There is a new clos_cbm table which keeps a 1:1
> mapping between closid and capacity bit mask (cbm)
> and a count of usage of closid. Each task would be ass
On Thu, 1 Oct 2015 23:09:34 -0700
Fenghua Yu wrote:
> This series has some preparatory patches and Intel cache allocation
> support.
Ping? What's the status of this series?
We badly need this series for KVM-RT workloads. I did try it and it
seems to work but, apart from small fixable issues wh
On Thu, 1 Oct 2015 23:09:38 -0700
Fenghua Yu wrote:
> This patch includes CPUID enumeration routines for Cache allocation and
> new values to track resources to the cpuinfo_x86 structure.
>
> Cache allocation provides a way for the Software (OS/VMM) to restrict
> cache allocation to a defined '
On Wed, 7 Oct 2015 20:33:56 -0400
Chris Metcalf wrote:
> On 10/5/2015 1:07 PM, Luiz Capitulino wrote:
> > On Mon, 28 Sep 2015 11:17:20 -0400
> > Chris Metcalf wrote:
> >
> >> The new "task_isolation_debug" flag simplifies debugging
> >> of TAS
On Mon, 28 Sep 2015 11:17:20 -0400
Chris Metcalf wrote:
> The new "task_isolation_debug" flag simplifies debugging
> of TASK_ISOLATION kernels when processes are running in
> PR_TASK_ISOLATION_ENABLE mode. Such processes should get no
> interrupts from the kernel, and if they do, when this boot
On Wed, 30 Sep 2015 19:27:13 +0200
Peter Zijlstra wrote:
> On Wed, Sep 30, 2015 at 01:16:10PM -0400, Luiz Capitulino wrote:
> > On Wed, 30 Sep 2015 17:48:35 +0200
> > Peter Zijlstra wrote:
>
> > > Ideally every cpuidle driver would get 'polling' as a
> &
On Wed, 30 Sep 2015 17:48:35 +0200
Peter Zijlstra wrote:
> On Wed, Sep 23, 2015 at 03:17:59AM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, September 22, 2015 04:34:19 PM Luiz Capitulino wrote:
> > > Hi,
> >
> > Hi,
> >
> > Please always CC patches
On Thu, 24 Sep 2015 16:44:18 +0200
Frederic Weisbecker wrote:
> On Thu, Sep 10, 2015 at 03:58:27PM -0400, Luiz Capitulino wrote:
> > tick_nohz_full_kick_cpu() performs the same check.
> >
> > Signed-off-by: Luiz Capitulino
> > ---
> > kernel/sched/sched.h | 20
On Wed, 23 Sep 2015 03:17:59 +0200
"Rafael J. Wysocki" wrote:
> On Tuesday, September 22, 2015 04:34:19 PM Luiz Capitulino wrote:
> > Hi,
>
> Hi,
>
> Please always CC patches related to power management to
> linux...@vger.kernel.org.
>
> Also CCi
Signed-off-by: Luiz Capitulino
---
kernel/sched/idle.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 8f177c7..93d0657 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -52,7 +52,7 @@ static int __init
.
This change should not be visible to arch code calling
cpu_idle_poll_ctrl().
Signed-off-by: Luiz Capitulino
---
kernel/sched/idle.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index
cpu_idle_poll_ctrl(enable or false) calls have to match to
enable or disable idle polling
Luiz Capitulino (3):
sched/idle: cpu_idle_poll(): drop unused return code
sched/idle: make cpu_idle_force_poll per-cpu
sched/idle: run-time support for setting idle polling
driv
o note that the system administrator
can't undo what was set by arch code. That is, if
arch code enables idle=poll by calling cpu_idle_poll_ctrl(true),
the system administrator won't be able to unset it.
Signed-off-by: Luiz Capitulino
---
drivers/base/cpu.c | 44
On Thu, 3 Sep 2015 01:46:24 +
"Jiang, Yunhong" wrote:
> Hi, Frederic
> I noticed currently the tick_nohz_idle_exit() will always restart the
> sched_tick, even when it's on the nohz_full cpu. I'm not sure if we can keep
> the sched_tick stopped if it's on a nohz_full_cpu. The sched ti
Signed-off-by: Luiz Capitulino
---
kernel/time/tick-sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 3319e16..8d45638 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -155,7 +155,7
tick_nohz_full_kick_cpu() performs the same check.
Signed-off-by: Luiz Capitulino
---
kernel/sched/sched.h | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 68cda11..102eb18 100644
--- a/kernel/sched
It's only called by tick_nohz_init().
Signed-off-by: Luiz Capitulino
---
kernel/time/tick-sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 8d45638..4cc6df03 100644
--- a/kernel/time/tick-sched.c
+++ b/k
Hi,
These are a few minor cleanups I did while doing a code reading,
patches should be self explanatory.
Luiz Capitulino (3):
nohz: mark tick_nohz_full_running as __read_mostly
nohz: mark tick_nohz_init_all() as __init
sched: add_nr_running(): drop tick_nohz_full_cpu() check
kernel/sched
On Tue, 1 Sep 2015 22:47:24 +0200
Frederic Weisbecker wrote:
> On Tue, Sep 01, 2015 at 07:14:13PM +, Jiang, Yunhong wrote:
> > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > > index 8b864ec..0902e4d 100644
> > > --- a/kernel/sched/core.c
> > > +++ b/kernel/sched/core.c
> > > @@
cause a system hang.
> Seen when running arm:multi_v7_defconfig in qemu with devicetree file
> vexpress-v2p-ca9.
>
> Fixes: 75e3b37d0598 ("hrtimer: Drop return code of hrtimer_switch_to_hres()")
> Cc: Luiz Capitulino
> Signed-off-by: Guenter Roeck
Thanks for cat
Commit-ID: 75e3b37d059856a972a5bf2bdfeac0f0f2db9ea3
Gitweb: http://git.kernel.org/tip/75e3b37d059856a972a5bf2bdfeac0f0f2db9ea3
Author: Luiz Capitulino
AuthorDate: Tue, 11 Aug 2015 16:40:43 -0400
Committer: Thomas Gleixner
CommitDate: Mon, 17 Aug 2015 23:19:03 +0200
hrtimer: Drop
It's not checked by the caller.
Signed-off-by: Luiz Capitulino
---
kernel/time/hrtimer.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 5c7ae4b..55575d4 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrti
Commit-ID: d74892c5b291c0010295d26d6b1e11cd70451722
Gitweb: http://git.kernel.org/tip/d74892c5b291c0010295d26d6b1e11cd70451722
Author: Luiz Capitulino
AuthorDate: Wed, 29 Jul 2015 15:14:17 -0400
Committer: Thomas Gleixner
CommitDate: Sat, 1 Aug 2015 12:00:13 +0200
clockevents: Drop
On Thu, 30 Jul 2015 02:44:45 +0200
Frederic Weisbecker wrote:
>
> On Wed, Jul 29, 2015 at 01:24:16PM -0400, Chris Metcalf wrote:
> > On 07/29/2015 09:23 AM, Frederic Weisbecker wrote:
> > >>At a higher level, is the posix-cpu-timers code here really providing the
> > >>>right semantics? It seems
The same check is performed by tick_check_percpu().
Signed-off-by: Luiz Capitulino
---
kernel/time/tick-common.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index f8bf475..d11c55b 100644
--- a/kernel/time/tick-common.c
+++ b/kernel
On Thu, 21 May 2015 21:41:23 -0300
Marcelo Tosatti wrote:
> On Mon, May 18, 2015 at 10:13:03PM -0400, Sasha Levin wrote:
> > On 05/18/2015 10:02 PM, Sasha Levin wrote:
> > > On 05/18/2015 08:13 PM, Marcelo Tosatti wrote:
> > >> GOn Mon, May 18, 2015 at 07:45:41PM -0400, Sasha Levin wrote:
> > >>>
igned-off-by: Marcelo Tosatti
Tested-by: Luiz Capitulino
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index cc2c759..ea40d24 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2188,6 +2188,8 @@ int kvm_set_msr_common(struct kvm_v
...]
>
> I've bisected it to:
Thanks for bisecting. You just boot a guest to reproduce this? How
many vCPUs does the guest have?
Paolo, I think it's better to drop this patch for now.
>
>
> commit ff7bbb9c6ab6e6620429daeff39424bbde1a94b4
> Author: Luiz Capitulino
&
On Sat, 11 Apr 2015 11:25:49 +0200 (CEST)
Thomas Gleixner wrote:
> On Fri, 10 Apr 2015, Luiz Capitulino wrote:
> > On Fri, 10 Apr 2015 15:09:07 -0300
> > > It seems a valid solution for this interrupt is to program
> > > sched_timer to the nearest future possible.
On Fri, 10 Apr 2015 15:09:07 -0300
Marcelo Tosatti wrote:
> On Wed, Apr 08, 2015 at 12:12:45AM +0200, Frederic Weisbecker wrote:
> > On Tue, Apr 07, 2015 at 11:10:49PM +0200, Thomas Gleixner wrote:
> > > On Mon, 6 Apr 2015, Marcelo Tosatti wrote:
> > > > It is only necessary to raise timer softir
On Tue, 31 Mar 2015 20:18:36 -0300
Marcelo Tosatti wrote:
> On Tue, Mar 31, 2015 at 05:02:38PM +0200, Frederic Weisbecker wrote:
> > On Tue, Mar 31, 2015 at 10:27:26AM -0400, Rik van Riel wrote:
> > > CPUs with nohz_full do not want disruption from timer interrupts,
> > > or other random system t
sz=1G.
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Luiz Capitulino
> Cc: Naoya Horiguchi
> Cc: Andi Kleen
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> ---
> arch/x86/mm/hugetlbpage.c | 11 +++
> 1 file chang
of date
information. Further information about arch-specific
support and available features can be obtained in the
hugetlb documentation.
Signed-off-by: Luiz Capitulino
---
Documentation/kernel-parameters.txt | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/Documentation
Hi,
This series contains three independent patches for hugetlb. The first one
is a doc fix, the second and third ones are little code improvements.
Please, check individual patches for details.
Luiz Capitulino (3):
hugetlb: fix hugepages= entry in kernel-parameters.txt
hugetlb
No reason to duplicate the code of an existing macro.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 9fd7227..a10fd57 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1457,7 +1457,7 @@ int
This function is only called during initialization.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a10fd57..9785546 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2083,7 +2083,7 @@ static
c64 supports 4K and 16M. A TLB is a cache of virtual-to-physical
> translations. Typically this is a very scarce resource on processor.
Looks good to me:
Reviewed-by: Luiz Capitulino
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
On Sat, 1 Nov 2014 01:01:57 +0900
Masanari Iida wrote:
> This patch add 1GB large page support information on
> x86_64 architecture in Documentation/vm/hugetlbpage.txt.
>
> Signed-off-by: Masanari Iida
> ---
> Documentation/vm/hugetlbpage.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 dele
On Mon, 15 Sep 2014 17:13:39 -0700 (PDT)
David Rientjes wrote:
> On Mon, 15 Sep 2014, Luiz Capitulino wrote:
>
> > The setup_node_data() function allocates a pg_data_t object, inserts it
> > into the node_data[] array and initializes the following fields: node_id,
>
u/kvm.
PS: The wrong memory range reported by setup_node_data() seems to be
harmless in the current kernel because it's just not used. However,
that bad range is used in kernel 2.6.32 to initialize the old boot
memory allocator, which causes a crash during boot.
Signed-off-by: Luiz
On Tue, 8 Jul 2014 15:11:13 -0700
Andrew Morton wrote:
> On Wed, 2 Jul 2014 17:44:46 -0700 (PDT) David Rientjes
> wrote:
>
> > > > @@ -2248,36 +2257,18 @@ static int hugetlb_sysctl_handler_common(bool
> > > > obey_mempolicy,
> > > > void __user *buffer, size_t *length
metal NUMA machine and Linux
as a numa guest on hyperv and qemu/kvm.
PS: The wrong memory range reported by setup_node_data() seems to be
harmless in the current kernel because it's just not used. However,
that bad range is used in kernel 2.6.32 to initialize the old boot
memory allo
On Wed, 2 Jul 2014 16:20:47 -0700 (PDT)
David Rientjes wrote:
> On Wed, 2 Jul 2014, Luiz Capitulino wrote:
>
> > > With this patch, the dmesg changes break one of my scripts that we use to
> > > determine the start and end address of a node (doubly bad because there
On Wed, 2 Jul 2014 17:44:46 -0700 (PDT)
David Rientjes wrote:
> On Wed, 2 Jul 2014, Luiz Capitulino wrote:
>
> > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > --- a/mm/hugetlb.c
> > > +++ b/mm/hugetlb.c
> > > @@ -1734,21 +1734,13 @@ stat
On Mon, 30 Jun 2014 17:46:35 -0700 (PDT)
David Rientjes wrote:
> They are unnecessary: "zero" can be used in place of "hugetlb_zero" and
> passing extra2 == NULL is equivalent to infinity.
>
> Signed-off-by: David Rientjes
Reviewed-by: Luiz Capitulino
>
On Mon, 30 Jun 2014 16:57:06 -0700 (PDT)
David Rientjes wrote:
> Three different interfaces alter the maximum number of hugepages for an
> hstate:
>
> - /proc/sys/vm/nr_hugepages for global number of hugepages of the default
>hstate,
>
> - /sys/kernel/mm/hugepages/hugepages-X/nr_hugepages
On Mon, 30 Jun 2014 16:42:39 -0700 (PDT)
David Rientjes wrote:
> On Thu, 19 Jun 2014, Luiz Capitulino wrote:
>
> > The setup_node_data() function allocates a pg_data_t object, inserts it
> > into the node_data[] array and initializes the following fields:
> > nod
On Thu, 26 Jun 2014 10:51:11 -0400
Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/19/2014 10:20 PM, Luiz Capitulino wrote:
>
> > @@ -523,8 +508,17 @@ static int __init numa_register_memblks(struct
> > numa_meminfo *mi) en
achine and Linux
as a numa guest on hyperv and qemu/kvm.
PS: The wrong memory range reported by setup_node_data() seems to be
harmless in the current kernel because it's just not used. However,
that bad range is used in kernel 2.6.32 to initialize the old boot
memory allocator, whi
Yinghai, sorry for my late reply.
On Mon, 9 Jun 2014 15:13:41 -0700
Yinghai Lu wrote:
> On Mon, Jun 9, 2014 at 12:03 PM, Luiz Capitulino
> wrote:
> > On Sun, 8 Jun 2014 18:29:11 -0700
> > Yinghai Lu wrote:
> >
> >> On Sun, Jun 8, 2014 at 3:14
On Tue, 10 Jun 2014 15:10:01 -0700 (PDT)
David Rientjes wrote:
> On Mon, 9 Jun 2014, Luiz Capitulino wrote:
>
> > > > > > diff --git a/arch/x86/include/asm/numa.h
> > > > > > b/arch/x86/include/asm/numa.h
> > > > > > index 4064aca..
On Mon, 9 Jun 2014 14:57:16 -0700 (PDT)
David Rientjes wrote:
> On Mon, 9 Jun 2014, Luiz Capitulino wrote:
>
> > > > diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
> > > > index 4064aca..01b493e 100644
> > > > --- a/arch/x86
On Sun, 8 Jun 2014 18:29:11 -0700
Yinghai Lu wrote:
> On Sun, Jun 8, 2014 at 3:14 PM, Luiz Capitulino
> wrote:
> > In short, I believe this is just dead code for the upstream kernel but this
> > causes a bug for 2.6.32 based kernels.
> >
> > The setup_node_data()
On Sun, 8 Jun 2014 15:25:50 -0700 (PDT)
David Rientjes wrote:
> On Sun, 8 Jun 2014, Luiz Capitulino wrote:
>
> > diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
> > index 4064aca..01b493e 100644
> > --- a/arch/x86/include/asm/numa.h
> > +++
rigger whenever the memory range
start address is rounded up, as it will always be greater than what is
reported in the SRAT table. This is true when the 2.6.32 kernel runs as a
HyperV guest on Windows Server 2012. Dropping ZONE_ALIGN solves the
problem there.
Signed-off-by: Luiz Capitulino
---
arch/
On Tue, 22 Apr 2014 14:55:46 -0700
Andrew Morton wrote:
> On Tue, 22 Apr 2014 17:37:26 -0400 Luiz Capitulino
> wrote:
>
> > On Thu, 17 Apr 2014 16:01:10 -0700
> > Andrew Morton wrote:
> >
> > > On Thu, 10 Apr 2014 13:58:40 -0400 Luiz Capitulino
>
On Wed, 23 Apr 2014 10:48:27 -0700
Randy Dunlap wrote:
> On 04/23/14 10:41, Luiz Capitulino wrote:
> > On Wed, 23 Apr 2014 10:10:29 -0700
> > Randy Dunlap wrote:
> >
> >> On 04/22/14 15:21, a...@linux-foundation.org wrote:
> >>> The mm-of-the-moment s
On Wed, 23 Apr 2014 10:10:29 -0700
Randy Dunlap wrote:
> On 04/22/14 15:21, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2014-04-22-15-20 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for mm-of-the-moment:
On Thu, 17 Apr 2014 16:01:10 -0700
Andrew Morton wrote:
> On Thu, 10 Apr 2014 13:58:40 -0400 Luiz Capitulino
> wrote:
>
> > The HugeTLB subsystem uses the buddy allocator to allocate hugepages during
> > runtime. This means that hugepages allocation during runtime is lim
On Thu, 17 Apr 2014 16:00:39 -0700
Andrew Morton wrote:
> On Thu, 10 Apr 2014 13:58:45 -0400 Luiz Capitulino
> wrote:
>
> > HugeTLB is limited to allocating hugepages whose size are less than
> > MAX_ORDER order. This is so because HugeTLB allocates hugepages via
&g
On Thu, 17 Apr 2014 11:52:42 -0700
Andrew Morton wrote:
> On Thu, 17 Apr 2014 11:13:05 -0400 Luiz Capitulino
> wrote:
>
> > On Thu, 10 Apr 2014 13:58:40 -0400
> > Luiz Capitulino wrote:
> >
> > > [Full introduction right after t
On Thu, 10 Apr 2014 13:58:40 -0400
Luiz Capitulino wrote:
> [Full introduction right after the changelog]
>
> Changelog
> -
>
> v3
>
> - Dropped unnecessary WARN_ON() call [Kirill]
> - Always check if the pfn range lies within a zone [Yasuaki]
> - Renam
This function is going to be used by non-init code in a future
commit.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index dd30f22..957231b 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -690,8
Next commit will add new code which will want to call
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino
Reviewed-by
t series it was agreed that having runtime
allocation support for gigantic pages was a better solution.
Luiz Capitulino (5):
hugetlb: prep_compound_gigantic_page(): drop __init marker
hugetlb: add hstate_is_gigantic()
hugetlb: update_and_free_page(): don't clear PG_reserved bit
hugetlb: mov
r_overcommit_hugepages > 0. The reason is that I don't
think it's reasonable to do the hard and long work required for
allocating a gigantic page at fault time. But it should be simple
to add this if wanted
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 167
Hugepages pages never get the PG_reserved bit set, so don't clear it.
However, note that if the bit gets mistakenly set free_pages_check() will
catch it.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c
Signed-off-by: Luiz Capitulino
Reviewed-by: Andrea Arcangeli
Reviewed-by: Naoya Horiguchi
Reviewed-by: Yasuaki Ishimatsu
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28 ++--
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include
On Wed, 9 Apr 2014 09:42:01 +0900
Yasuaki Ishimatsu wrote:
> (2014/04/09 4:02), Luiz Capitulino wrote:
> > HugeTLB is limited to allocating hugepages whose size are less than
> > MAX_ORDER order. This is so because HugeTLB allocates hugepages via
> > the buddy allocator. Gi
On Tue, 8 Apr 2014 15:51:02 -0700
Andrew Morton wrote:
> On Mon, 7 Apr 2014 14:49:35 -0400 Luiz Capitulino
> wrote:
>
> > > > ---
> > > > arch/x86/include/asm/hugetlb.h | 10 +++
> > > > mm/hugetlb.c | 177
> > > > +
On Tue, 8 Apr 2014 23:51:26 +0300
"Kirill A. Shutemov" wrote:
> On Tue, Apr 08, 2014 at 03:02:18PM -0400, Luiz Capitulino wrote:
> > Hugepages pages never get the PG_reserved bit set, so don't clear it. But
> > add a warning just in case.
>
> I don't th
On Tue, 08 Apr 2014 15:51:51 -0400
Naoya Horiguchi wrote:
> Hi Luiz,
>
> On Tue, Apr 08, 2014 at 03:02:16PM -0400, Luiz Capitulino wrote:
> > This function is going to be used by non-init code in a future
> > commit.
> >
> > Signed-off-by: Luiz Capituli
pped incomplete multi-arch support [Naoya]
- Added patch to drop __init from prep_compound_gigantic_page()
- Restricted the feature to x86_64 (more details in patch 5/5)
- Added reviewed-bys plus minor changelog changes
Luiz Capitulino (5):
hugetlb: prep_compound_gigantic_page(): drop __init marker
Signed-off-by: Luiz Capitulino
Reviewed-by: Andrea Arcangeli
Reviewed-by: Naoya Horiguchi
Reviewed-by: Yasuaki Ishimatsu
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28 ++--
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include
Next commit will add new code which will want to call
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino
Reviewed-by
Hugepages pages never get the PG_reserved bit set, so don't clear it. But
add a warning just in case.
Signed-off-by: Luiz Capitulino
Reviewed-by: Andrea Arcangeli
Reviewed-by: Naoya Horiguchi
Reviewed-by: Yasuaki Ishimatsu
---
mm/hugetlb.c | 5 +++--
1 file changed, 3 insertions(
r_overcommit_hugepages > 0. The reason is that I don't
think it's reasonable to do the hard and long work required for
allocating a gigantic page at fault time. But it should be simple
to add this if wanted
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 158
This function is going to be used by non-init code in a future
commit.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7c02b9d..319db28 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -689,8
On Fri, 4 Apr 2014 12:05:17 +0900
Yasuaki Ishimatsu wrote:
> (2014/04/03 3:08), Luiz Capitulino wrote:
> > HugeTLB is limited to allocating hugepages whose size are less than
> > MAX_ORDER order. This is so because HugeTLB allocates hugepages via
> > the buddy allocator. Gi
Hugepages pages never get the PG_reserved bit set, so don't clear it. But
add a warning just in case.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8c50547..7e07e47 100644
---
39593335312191&w=2
During the discussion of that series it was agreed that having runtime
allocation support for gigantic pages was a better solution.
Luiz Capitulino (4):
hugetlb: add hstate_is_gigantic()
hugetlb: update_and_free_page(): don't clear PG_reserved bit
hugetlb: move helpers up
Next commit will add new code which will want to call the
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino
---
mm
Signed-off-by: Luiz Capitulino
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28 ++--
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 8c43cc4..8590134 100644
--- a/include/linux
ge at fault time. But it should be simple
to add this if wanted
Signed-off-by: Luiz Capitulino
---
arch/x86/include/asm/hugetlb.h | 10 +++
mm/hugetlb.c | 177 ++---
2 files changed, 176 insertions(+), 11 deletions(-)
diff --git a/arch/x86/i
FAIL? I think it shouldn't, as we don't allocate from
the buddy
Signed-off-by: Luiz Capitulino
---
This patch is a follow up for this series:
http://marc.info/?l=linux-mm&m=139234006724423&w=2
That series introduced a command-line option to allow the user to specify from
On Thu, 20 Feb 2014 15:15:46 -0800 (PST)
David Rientjes wrote:
> Do I really need to do your work for you and work on 1GB hugepages at
> runtime, which many more people would be interested in? Or are we just
> seeking the easiest way out here with something that shuts the customer up
> and le
On Wed, 19 Feb 2014 20:51:55 -0800 (PST)
David Rientjes wrote:
> On Wed, 19 Feb 2014, Luiz Capitulino wrote:
>
> > > Yes, my concrete objection is that the command line interface is
> > > unnecessary if you can dynamically allocate and free 1GB pages at runtime
> &
101 - 200 of 296 matches
Mail list logo
