[PATCH] MAINTAINERS: Update the UV architecture to current addresses

After the buyout/merger our @sgi.com address are slowing being less useful. So make sure we are can be contacted properly. Signed-off-by: Nathan Zimmer <nathan.zim...@hpe.com> Signed-off-by: Mike Travis <mike.tra...@hpe.com> --- MAINTAINERS | 10 ++ 1 file changed, 10 inserti

[PATCH] MAINTAINERS: Update the UV architecture to current addresses

After the buyout/merger our @sgi.com address are slowing being less useful. So make sure we are can be contacted properly. Signed-off-by: Nathan Zimmer Signed-off-by: Mike Travis --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index

Re: console issue since 3.6, console=ttyS1 hangs

On 11/05/2016 06:44 PM, Maciej W. Rozycki wrote: On Fri, 4 Nov 2016, Peter Hurley wrote: These bios screens do not have any mention of PNP settings. I am getting output over the console (via ipmi) until the boot hangs. Yeah, probably the device actually decodes io address access anyway, but

Re: console issue since 3.6, console=ttyS1 hangs

On 11/05/2016 06:44 PM, Maciej W. Rozycki wrote: On Fri, 4 Nov 2016, Peter Hurley wrote: These bios screens do not have any mention of PNP settings. I am getting output over the console (via ipmi) until the boot hangs. Yeah, probably the device actually decodes io address access anyway, but

Re: console issue since 3.6, console=ttyS1 hangs

On 11/05/2016 06:44 PM, Maciej W. Rozycki wrote: On Fri, 4 Nov 2016, Peter Hurley wrote: These bios screens do not have any mention of PNP settings. I am getting output over the console (via ipmi) until the boot hangs. Yeah, probably the device actually decodes io address access anyway, but

Re: console issue since 3.6, console=ttyS1 hangs

On 11/05/2016 06:44 PM, Maciej W. Rozycki wrote: On Fri, 4 Nov 2016, Peter Hurley wrote: These bios screens do not have any mention of PNP settings. I am getting output over the console (via ipmi) until the boot hangs. Yeah, probably the device actually decodes io address access anyway, but

Re: console issue since 3.6, console=ttyS1 hangs

On Thu, Nov 03, 2016 at 06:25:46PM -0600, Peter Hurley wrote: > On Wed, Nov 2, 2016 at 9:29 AM, Nathan Zimmer <nzim...@sgi.com> wrote: > > On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurley wrote: > >> On Mon, Oct 31, 2016 at 2:27 PM, Sean Young <s...@mess.org>

Re: console issue since 3.6, console=ttyS1 hangs

On Thu, Nov 03, 2016 at 06:25:46PM -0600, Peter Hurley wrote: > On Wed, Nov 2, 2016 at 9:29 AM, Nathan Zimmer wrote: > > On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurley wrote: > >> On Mon, Oct 31, 2016 at 2:27 PM, Sean Young wrote: > >> > On Sun, Oct 30, 20

Re: console issue since 3.6, console=ttyS1 hangs

On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurley wrote: > On Mon, Oct 31, 2016 at 2:27 PM, Sean Young wrote: > > On Sun, Oct 30, 2016 at 10:33:02AM -0500, Nathan wrote: > >> I think this should be PNP0501 instead of PNP0c02. > >> Once I alter that then when I boot the serial

Re: console issue since 3.6, console=ttyS1 hangs

On Mon, Oct 31, 2016 at 08:55:49PM -0600, Peter Hurley wrote: > On Mon, Oct 31, 2016 at 2:27 PM, Sean Young wrote: > > On Sun, Oct 30, 2016 at 10:33:02AM -0500, Nathan wrote: > >> I think this should be PNP0501 instead of PNP0c02. > >> Once I alter that then when I boot the serial comes up on irq

Re: console issue since 3.6, console=ttyS1 hangs

On Thu, Oct 27, 2016 at 09:19:16PM +0100, Sean Young wrote: > On Wed, Oct 26, 2016 at 01:16:16PM -0500, Nathan Zimmer wrote: > > On 10/25/2016 03:41 PM, Sean Young wrote: > > >On Mon, Oct 24, 2016 at 04:49:25PM -0500, Nathan Zimmer wrote: > > >>[1.565062] seria

Re: console issue since 3.6, console=ttyS1 hangs

On Thu, Oct 27, 2016 at 09:19:16PM +0100, Sean Young wrote: > On Wed, Oct 26, 2016 at 01:16:16PM -0500, Nathan Zimmer wrote: > > On 10/25/2016 03:41 PM, Sean Young wrote: > > >On Mon, Oct 24, 2016 at 04:49:25PM -0500, Nathan Zimmer wrote: > > >>[1.565062] seria

Re: console issue since 3.6, console=ttyS1 hangs

On 10/25/2016 03:41 PM, Sean Young wrote: On Mon, Oct 24, 2016 at 04:49:25PM -0500, Nathan Zimmer wrote: [0.974874] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active) [0.975038] pnp 00:04: parse resource options [0.975048] pnp 00:04: dependent set 0 (acceptable) io

Re: console issue since 3.6, console=ttyS1 hangs

On 10/25/2016 03:41 PM, Sean Young wrote: On Mon, Oct 24, 2016 at 04:49:25PM -0500, Nathan Zimmer wrote: [0.974874] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active) [0.975038] pnp 00:04: parse resource options [0.975048] pnp 00:04: dependent set 0 (acceptable) io

Re: console issue since 3.6, console=ttyS1 hangs

On Mon, Oct 24, 2016 at 02:52:35PM +0100, Sean Young wrote: > On Fri, Oct 21, 2016 at 10:55:40AM -0500, Nathan Zimmer wrote: > > It didn't seem to make a difference as far as output. > > Did I miss a config option? or something else? > > > > [0.00] Linux versi

Re: console issue since 3.6, console=ttyS1 hangs

On Mon, Oct 24, 2016 at 02:52:35PM +0100, Sean Young wrote: > On Fri, Oct 21, 2016 at 10:55:40AM -0500, Nathan Zimmer wrote: > > It didn't seem to make a difference as far as output. > > Did I miss a config option? or something else? > > > > [0.00] Linux versi

Re: console issue since 3.6, console=ttyS1 hangs

0x2f8 (irq = 3) is a 16550A [2.097844] serial 00:04: unable to assign resources [2.098303] serial: probe of 00:04 failed with error -16 On 10/20/2016 03:10 PM, Sean Young wrote: On Wed, Oct 19, 2016 at 05:13:41PM -0500, Nathan Zimmer wrote: On 10/19/2016 04:07 AM, Sean Young wrote: So

Re: console issue since 3.6, console=ttyS1 hangs

0x2f8 (irq = 3) is a 16550A [2.097844] serial 00:04: unable to assign resources [2.098303] serial: probe of 00:04 failed with error -16 On 10/20/2016 03:10 PM, Sean Young wrote: On Wed, Oct 19, 2016 at 05:13:41PM -0500, Nathan Zimmer wrote: On 10/19/2016 04:07 AM, Sean Young wrote: So

Re: console issue since 3.6, console=ttyS1 hangs

On 10/19/2016 04:07 AM, Sean Young wrote: On Tue, Oct 18, 2016 at 02:29:30PM -0500, Nathan Zimmer wrote: On Tue, Oct 18, 2016 at 07:05:18PM +0100, Sean Young wrote: On Tue, Oct 18, 2016 at 11:40:04AM -0500, Nathan Zimmer wrote: 3.7.0 cat /sys/bus/pnp/drivers/serial/*/resources state

Re: console issue since 3.6, console=ttyS1 hangs

On 10/19/2016 04:07 AM, Sean Young wrote: On Tue, Oct 18, 2016 at 02:29:30PM -0500, Nathan Zimmer wrote: On Tue, Oct 18, 2016 at 07:05:18PM +0100, Sean Young wrote: On Tue, Oct 18, 2016 at 11:40:04AM -0500, Nathan Zimmer wrote: 3.7.0 cat /sys/bus/pnp/drivers/serial/*/resources state

Re: console issue since 3.6, console=ttyS1 hangs

/pnp0/*/resources" might be helpful. On Mon, Oct 17, 2016 at 11:41:40AM -0500, Nathan Zimmer wrote: > Ok I'll get that sometime tomorrow. Right now they pulled it down > maintenance... > > On Mon, Oct 17, 2016 at 04:19:07PM +0100, Sean Young wrote: > > On Mon, Oct

Re: console issue since 3.6, console=ttyS1 hangs

/pnp0/*/resources" might be helpful. On Mon, Oct 17, 2016 at 11:41:40AM -0500, Nathan Zimmer wrote: > Ok I'll get that sometime tomorrow. Right now they pulled it down > maintenance... > > On Mon, Oct 17, 2016 at 04:19:07PM +0100, Sean Young wrote: > > On Mon, Oct

Re: console issue since 3.6, console=ttyS1 hangs

Ok I'll get that sometime tomorrow. Right now they pulled it down maintenance... On Mon, Oct 17, 2016 at 04:19:07PM +0100, Sean Young wrote: > On Mon, Oct 17, 2016 at 09:49:51AM -0500, Nathan Zimmer wrote: > > A cluster client recently tried to update from Sles11 to Sles12 and found in

Re: console issue since 3.6, console=ttyS1 hangs

Ok I'll get that sometime tomorrow. Right now they pulled it down maintenance... On Mon, Oct 17, 2016 at 04:19:07PM +0100, Sean Young wrote: > On Mon, Oct 17, 2016 at 09:49:51AM -0500, Nathan Zimmer wrote: > > A cluster client recently tried to update from Sles11 to Sles12 and found in

console issue since 3.6, console=ttyS1 hangs

A cluster client recently tried to update from Sles11 to Sles12 and found in some cases the boxes would hang in early boot. It came down to console=ttyS1 on the command line. After a bisection I found it happended in here: commit 835d844d1a28efba81d5aca7385e24c29d3a6db2 Author: Sean Young

console issue since 3.6, console=ttyS1 hangs

A cluster client recently tried to update from Sles11 to Sles12 and found in some cases the boxes would hang in early boot. It came down to console=ttyS1 on the command line. After a bisection I found it happended in here: commit 835d844d1a28efba81d5aca7385e24c29d3a6db2 Author: Sean Young

[PATCH] MAINTAINERS: Add in a maintainer and mailing list for UV Architecture

We at SGI really should be stepping up here, if for no other reason then we have the hardware to test the occasional change. I am more then a little embarrassed that this hadn't been done earlier. Also adding an internal mailing list for when people are out of office. Signed-off-by: Nathan Zimmer

[PATCH] MAINTAINERS: Add in a maintainer and mailing list for UV Architecture

We at SGI really should be stepping up here, if for no other reason then we have the hardware to test the occasional change. I am more then a little embarrassed that this hadn't been done earlier. Also adding an internal mailing list for when people are out of office. Signed-off-by: Nathan Zimmer

[PATCH] mempolicy: convert the shared_policy lock to a rwlock

-by: David Rientjes Cc: Andrew Morton Cc: Nadia Yvette Chambers Cc: Naoya Horiguchi Cc: Mel Gorman Cc: "Aneesh Kumar K.V" Cc: linux-kernel@vger.kernel.org Cc: linux...@kvack.org Signed-off-by: Nathan Zimmer --- fs/hugetlbfs/inode.c | 2 +- include/linux/mempolicy.h |

[PATCH] mempolicy: convert the shared_policy lock to a rwlock

.ku...@linux.vnet.ibm.com> Cc: linux-kernel@vger.kernel.org Cc: linux...@kvack.org Signed-off-by: Nathan Zimmer <nzim...@sgi.com> --- fs/hugetlbfs/inode.c | 2 +- include/linux/mempolicy.h | 2 +- mm/mempolicy.c| 20 ++-- 3 files changed, 12 insertions(+), 12

[RFC] mempolicy: convert the shared_policy lock to a rwlock

: Andrew Morton Cc: Naoya Horiguchi Cc: Mel Gorman Cc: "Aneesh Kumar K.V" Cc: linux-kernel@vger.kernel.org Cc: linux...@kvack.org Signed-off-by: Nathan Zimmer --- include/linux/mempolicy.h | 2 +- mm/mempolicy.c| 16 2 files changed, 9 insertions(+), 9

[RFC] mempolicy: convert the shared_policy lock to a rwlock

: Andrew Morton <a...@linux-foundation.org> Cc: Naoya Horiguchi <n-horigu...@ah.jp.nec.com> Cc: Mel Gorman <mgor...@suse.de> Cc: "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> Cc: linux-kernel@vger.kernel.org Cc: linux...@kvack.org Signed-off-by: Nathan Zimmer &l

Re: [tip:x86/platform] x86/uv/time: Migrate to new set-state interface

Yes, thank you for the correction. On 08/05/2015 12:15 AM, Viresh Kumar wrote: On 04-08-15, 10:25, Nathan Zimmer wrote: diff --git a/MAINTAINERS b/MAINTAINERS index 907ce01..9c2beb3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10885,6 +10885,15 @@ W: http://en.wikipedia.org/wiki/Util

Re: [tip:x86/platform] x86/uv/time: Migrate to new set-state interface

Yes, thank you for the correction. On 08/05/2015 12:15 AM, Viresh Kumar wrote: On 04-08-15, 10:25, Nathan Zimmer wrote: diff --git a/MAINTAINERS b/MAINTAINERS index 907ce01..9c2beb3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10885,6 +10885,15 @@ W: http://en.wikipedia.org/wiki/Util

Re: [tip:x86/platform] x86/uv/time: Migrate to new set-state interface

vide a nice catch all given a few people are subscribed to it. >From f5ef7784e0fe609a1d56cbaa20aea93e27cce274 Mon Sep 17 00:00:00 2001 From: Nathan Zimmer Date: Tue, 4 Aug 2015 09:56:05 -0500 Subject: [PATCH] MAINTAINERS: Add some maintainers for the UV architecture. Currently there is a lack of maintainers for the UV ar

Re: [tip:x86/platform] x86/uv/time: Migrate to new set-state interface

:00:00 2001 From: Nathan Zimmer nzim...@sgi.com Date: Tue, 4 Aug 2015 09:56:05 -0500 Subject: [PATCH] MAINTAINERS: Add some maintainers for the UV architecture. Currently there is a lack of maintainers for the UV architecture. We at SGI really should be stepping up here, if for no other reason

Re: [RFC] kthread_create_on_node is failing to honor the node choice

On Thu, Jul 09, 2015 at 03:12:59PM -0700, Andrew Morton wrote: > On Thu, 25 Jun 2015 16:44:13 -0500 Nathan Zimmer wrote: > > > In kthread_create_on_node we set_cpus_allowed to cpu_all_mask > > regardless of what the node is requested. > > This seems incorr

Re: [RFC] kthread_create_on_node is failing to honor the node choice

On Thu, Jul 09, 2015 at 03:12:59PM -0700, Andrew Morton wrote: On Thu, 25 Jun 2015 16:44:13 -0500 Nathan Zimmer nzim...@sgi.com wrote: In kthread_create_on_node we set_cpus_allowed to cpu_all_mask regardless of what the node is requested. This seems incorrect. The `node' arg

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

, Jun 24, 2015 at 11:50 PM, Nathan Zimmer wrote: My apologies for taking so long to get back to this. I think I did locate two potential sources of slowdown. One is the set_cpus_allowed_ptr as I have noted previously. However I only notice that on the very largest boxes. I did cobble together a patch

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

, Jun 24, 2015 at 11:50 PM, Nathan Zimmer nzim...@sgi.com wrote: My apologies for taking so long to get back to this. I think I did locate two potential sources of slowdown. One is the set_cpus_allowed_ptr as I have noted previously. However I only notice that on the very largest boxes. I did cobble

[RFC] kthread_create_on_node is failing to honor the node choice

In kthread_create_on_node we set_cpus_allowed to cpu_all_mask regardless of what the node is requested. This seems incorrect. Signed-off-by: Nathan Zimmer Cc: Andrew Morton Cc: Nishanth Aravamudan Cc: Tejun Heo Cc: Lai Jiangshan Cc: Mel Gorman Cc: linux-kernel@vger.kernel.org --- kernel

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

On Thu, Jun 25, 2015 at 09:48:55PM +0100, Mel Gorman wrote: > On Wed, Jun 24, 2015 at 05:50:28PM -0500, Nathan Zimmer wrote: > > My apologies for taking so long to get back to this. > > > > I think I did locate two potential sources of slowdown. > > One is the set_cpus_

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

On Thu, Jun 25, 2015 at 09:57:44PM +0100, Mel Gorman wrote: > On Thu, Jun 25, 2015 at 09:48:55PM +0100, Mel Gorman wrote: > > On Wed, Jun 24, 2015 at 05:50:28PM -0500, Nathan Zimmer wrote: > > > My apologies for taking so long to get back to this. > > > > > >

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

On Thu, Jun 25, 2015 at 09:48:55PM +0100, Mel Gorman wrote: On Wed, Jun 24, 2015 at 05:50:28PM -0500, Nathan Zimmer wrote: My apologies for taking so long to get back to this. I think I did locate two potential sources of slowdown. One is the set_cpus_allowed_ptr as I have noted

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

On Thu, Jun 25, 2015 at 09:57:44PM +0100, Mel Gorman wrote: On Thu, Jun 25, 2015 at 09:48:55PM +0100, Mel Gorman wrote: On Wed, Jun 24, 2015 at 05:50:28PM -0500, Nathan Zimmer wrote: My apologies for taking so long to get back to this. I think I did locate two potential sources

[RFC] kthread_create_on_node is failing to honor the node choice

In kthread_create_on_node we set_cpus_allowed to cpu_all_mask regardless of what the node is requested. This seems incorrect. Signed-off-by: Nathan Zimmer nzim...@sgi.com Cc: Andrew Morton a...@linux-foundation.org Cc: Nishanth Aravamudan n...@linux.vnet.ibm.com Cc: Tejun Heo t...@kernel.org Cc

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

ut/x86-mm-enable-deferred-struct-page-initialisation-on-x86-64.patch > http://ozlabs.org/~akpm/mmots/broken-out/mm-meminit-free-pages-in-large-chunks-where-possible.patch > http://ozlabs.org/~akpm/mmots/broken-out/mm-meminit-reduce-number-of-times-pageblocks-are-set-during-struct-page-init.patch &g

Re: [PATCH] mm: meminit: Finish initialisation of struct pages before basic setup

From: Nathan Zimmer nzim...@sgi.com Date: Thu, 11 Jun 2015 10:47:39 -0500 Subject: [RFC] Avoid the contention in set_cpus_allowed Noticing some scaling issues at larger box sizes (64 nodes+) I found that in some cases we are spending significant amounts of time in set_cpus_allowed_ptr. My

[RFC] iommu/vt-d: Use the SIRTP when enabling remapping

-by: Nathan Zimmer Signed-off-by: Gary Kroening Cc: Jan Kiszka Cc: Joerg Roedel --- drivers/iommu/intel_irq_remapping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c index a872874..f586e41 100644

[RFC] iommu/vt-d: Use the SIRTP when enabling remapping

-by: Nathan Zimmer nzim...@sgi.com Signed-off-by: Gary Kroening g...@sgi.com Cc: Jan Kiszka jan.kis...@siemens.com Cc: Joerg Roedel jroe...@suse.de --- drivers/iommu/intel_irq_remapping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers

Re: [RFC] Move the memory_notifier out of the memory_hotplug lock

On Wed, Feb 05, 2014 at 03:20:07PM -0800, David Rientjes wrote: > On Wed, 5 Feb 2014, Nathan Zimmer wrote: > > > > That looks a little problematic, what happens if a nid is being brought > > > online and a registered callback does something like allocate res

Re: [RFC] Move the memory_notifier out of the memory_hotplug lock

On Wed, Feb 05, 2014 at 03:20:07PM -0800, David Rientjes wrote: On Wed, 5 Feb 2014, Nathan Zimmer wrote: That looks a little problematic, what happens if a nid is being brought online and a registered callback does something like allocate resources for the arg-status_change_nid

Re: [RFC] Move the memory_notifier out of the memory_hotplug lock

On 02/05/2014 02:29 PM, David Rientjes wrote: On Wed, 5 Feb 2014, Nathan Zimmer wrote: diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 62a0cd1..a3cbd14 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -985,12 +985,12 @@ int __ref online_pages(unsigned long pfn

[RFC] Move the memory_notifier out of the memory_hotplug lock

There are a few spots where we call memory_notifier. This doesn't need to be done under lock since memory_notify is just a blocking_notifier_call_chain with it's own locking mechanism. This RFC is a follow on to the one I submitted earlier. (move register_memory_resource out of the

[RFC] Move the memory_notifier out of the memory_hotplug lock

There are a few spots where we call memory_notifier. This doesn't need to be done under lock since memory_notify is just a blocking_notifier_call_chain with it's own locking mechanism. This RFC is a follow on to the one I submitted earlier. (move register_memory_resource out of the

Re: [RFC] Move the memory_notifier out of the memory_hotplug lock

On 02/05/2014 02:29 PM, David Rientjes wrote: On Wed, 5 Feb 2014, Nathan Zimmer wrote: diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 62a0cd1..a3cbd14 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -985,12 +985,12 @@ int __ref online_pages(unsigned long pfn

[RFC] hotplug, memory: move register_memory_resource out of the lock_memory_hotplug

We don't need to do register_memory_resource() since it has its own lock and doesn't make any callbacks. Also register_memory_resource return NULL on failure so we don't have anything to cleanup at this point. The reason for this rfc is I was doing some experiments with hotplugging of memory on

[RFC] hotplug, memory: move register_memory_resource out of the lock_memory_hotplug

We don't need to do register_memory_resource() since it has its own lock and doesn't make any callbacks. Also register_memory_resource return NULL on failure so we don't have anything to cleanup at this point. The reason for this rfc is I was doing some experiments with hotplugging of memory on

Re: [PATCH 2/2 v2] epoll: Do not take global 'epmutex' for simple topologies

On Fri, Oct 04, 2013 at 11:16:12AM -0400, Jason Baron wrote: > On 10/03/2013 05:50 PM, Andrew Morton wrote: > > On Tue, 1 Oct 2013 17:08:14 + (GMT) Jason Baron > > wrote: > > > >> When calling EPOLL_CTL_ADD for an epoll file descriptor that is attached > >> directly to a wakeup source, we

Re: [PATCH 2/2 v2] epoll: Do not take global 'epmutex' for simple topologies

On Fri, Oct 04, 2013 at 11:16:12AM -0400, Jason Baron wrote: On 10/03/2013 05:50 PM, Andrew Morton wrote: On Tue, 1 Oct 2013 17:08:14 + (GMT) Jason Baron jba...@akamai.com wrote: When calling EPOLL_CTL_ADD for an epoll file descriptor that is attached directly to a wakeup source,

Re: [RFC] eventpoll: Move a kmem_cache_alloc and kmem_cache_free

On Mon, Sep 23, 2013 at 11:47:41AM -0500, Nathan Zimmer wrote: > On Mon, Sep 23, 2013 at 11:17:39AM -0400, Jason Baron wrote: > > On 09/19/2013 12:37 PM, Nathan Zimmer wrote: > > > On 09/18/2013 02:09 PM, Jason Baron wrote: > > >> On 09/13/2013 11:54 AM, Nathan Zi

Re: [RFC] eventpoll: Move a kmem_cache_alloc and kmem_cache_free

On Mon, Sep 23, 2013 at 11:47:41AM -0500, Nathan Zimmer wrote: On Mon, Sep 23, 2013 at 11:17:39AM -0400, Jason Baron wrote: On 09/19/2013 12:37 PM, Nathan Zimmer wrote: On 09/18/2013 02:09 PM, Jason Baron wrote: On 09/13/2013 11:54 AM, Nathan Zimmer wrote: We noticed some scaling issue

Re: [RFC] eventpoll: Move a kmem_cache_alloc and kmem_cache_free

On Mon, Sep 23, 2013 at 11:17:39AM -0400, Jason Baron wrote: > On 09/19/2013 12:37 PM, Nathan Zimmer wrote: > > On 09/18/2013 02:09 PM, Jason Baron wrote: > >> On 09/13/2013 11:54 AM, Nathan Zimmer wrote: > >>> We noticed some scaling issue in the SPECjbb benchmark

Re: [RFC] eventpoll: Move a kmem_cache_alloc and kmem_cache_free

On Mon, Sep 23, 2013 at 11:17:39AM -0400, Jason Baron wrote: On 09/19/2013 12:37 PM, Nathan Zimmer wrote: On 09/18/2013 02:09 PM, Jason Baron wrote: On 09/13/2013 11:54 AM, Nathan Zimmer wrote: We noticed some scaling issue in the SPECjbb benchmark. Running perf we found

Re: [RFC] eventpoll: Move a kmem_cache_alloc and kmem_cache_free

On 09/18/2013 02:09 PM, Jason Baron wrote: On 09/13/2013 11:54 AM, Nathan Zimmer wrote: We noticed some scaling issue in the SPECjbb benchmark. Running perf we found that the it was spending lots of time in SYS_epoll_ctl. In particular it is holding the epmutex. This patch helps by moving out

Re: [RFC] eventpoll: Move a kmem_cache_alloc and kmem_cache_free

On 09/18/2013 02:09 PM, Jason Baron wrote: On 09/13/2013 11:54 AM, Nathan Zimmer wrote: We noticed some scaling issue in the SPECjbb benchmark. Running perf we found that the it was spending lots of time in SYS_epoll_ctl. In particular it is holding the epmutex. This patch helps by moving out

[RFC] eventpoll: Move a kmem_cache_alloc and kmem_cache_free

/lkml/2011/2/25/297. Any thoughts? Cc: Al Viro Cc: Jason Baron Reported-by: Jerry Lohr Signed-off-by: Nathan Zimmer --- fs/eventpoll.c | 27 ++- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 9ad17b15..752e5ff 100644

[RFC] eventpoll: Move a kmem_cache_alloc and kmem_cache_free

/lkml/2011/2/25/297. Any thoughts? Cc: Al Viro v...@zeniv.linux.org.uk Cc: Jason Baron jba...@redhat.com Reported-by: Jerry Lohr gl...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com --- fs/eventpoll.c | 27 ++- 1 file changed, 18 insertions(+), 9 deletions(-) diff

[PATCH] Have __free_pages_memory() free in larger chunks.

Robin and I had been working on. Signed-off-by: Robin Holt Signed-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc: Mel Gorman --- mm/n

[PATCH] Have __free_pages_memory() free in larger chunks.

the boot time rfc Robin and I had been working on. Signed-off-by: Robin Holt robin.m.h...@gmail.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter Anvin h...@zytor.com To: Ingo Molnar mi...@kernel.org Cc: Linux Kernel linux-kernel@vger.kernel.org Cc: Linux MM linux...@kvack.org Cc: Rob

Re: [RFC v3 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator

On Wed, Aug 14, 2013 at 01:05:56PM +0200, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > [...] > > > > Ok, so I don't know all the issues, and in many ways I don't even really > > care. You could do it other ways, I don't think this is a big deal. The > > part I hate is the runtime

Re: [RFC v3 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator

On Wed, Aug 14, 2013 at 01:05:56PM +0200, Ingo Molnar wrote: * Linus Torvalds torva...@linux-foundation.org wrote: [...] Ok, so I don't know all the issues, and in many ways I don't even really care. You could do it other ways, I don't think this is a big deal. The part I hate is

Re: [RFC v3 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator

On Tue, Aug 13, 2013 at 10:51:37AM -0700, Linus Torvalds wrote: > I realize that benchmarking cares, and yes, I also realize that some > benchmarks actually want to reboot the machine between some runs just > to get repeatability, but if you're benchmarking a 16TB machine I'm > guessing any

Re: [RFC v3 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator

On 08/13/2013 01:04 PM, Mike Travis wrote: On 8/13/2013 10:51 AM, Linus Torvalds wrote: by the time you can log in. And if it then takes another ten minutes until you have the full 16TB initialized, and some things might be a tad slower early on, does anybody really care? The machine will be

Re: [RFC v3 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator

On 08/13/2013 01:04 PM, Mike Travis wrote: On 8/13/2013 10:51 AM, Linus Torvalds wrote: by the time you can log in. And if it then takes another ten minutes until you have the full 16TB initialized, and some things might be a tad slower early on, does anybody really care? The machine will be

Re: [RFC v3 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator

On Tue, Aug 13, 2013 at 10:51:37AM -0700, Linus Torvalds wrote: I realize that benchmarking cares, and yes, I also realize that some benchmarks actually want to reboot the machine between some runs just to get repeatability, but if you're benchmarking a 16TB machine I'm guessing any serious

[RFC v3 2/5] Have __free_pages_memory() free in larger chunks.

are increasing to the maximum size available. Signed-off-by: Robin Holt Signed-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc:

[RFC v3 5/5] Sparse initialization of struct page array.

the advantage of boot speed, this allows us the chance to use normal performance monitoring tools to determine where the bulk of time is spent during page initialization. Signed-off-by: Robin Holt Signed-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux M

[RFC v3 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator

at moving the reserved bit. __expand_page_initialization should only be called by ensure_pages_are_initialized Nathan Zimmer (1): Only set page reserved in the memblock region Robin Holt (4): memblock: Introduce a for_each_reserved_mem_region iterator. Have __free_pages_memory() free

[RFC v3 3/5] Move page initialization into a separate function.

-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc: Mel Gorman --- mm/mm_init.c| 2 +- mm/page_al

[RFC v3 4/5] Only set page reserved in the memblock region

Currently we when we initialze each page struct is set as reserved upon initialization. This changes to starting with the reserved bit clear and then only setting the bit in the reserved region. Signed-off-by: Robin Holt Signed-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo

[RFC v3 1/5] memblock: Introduce a for_each_reserved_mem_region iterator.

Signed-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc: Mel Gorman --- include/linux/memblock.h | 18 ++ mm/

[RFC v3 1/5] memblock: Introduce a for_each_reserved_mem_region iterator.

-by: Robin Holt h...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter Anvin h...@zytor.com To: Ingo Molnar mi...@kernel.org Cc: Linux Kernel linux-kernel@vger.kernel.org Cc: Linux MM linux...@kvack.org Cc: Rob Landley r...@landley.net Cc: Mike Travis tra...@sgi.com Cc: Daniel J Blueman dan

[RFC v3 4/5] Only set page reserved in the memblock region

Currently we when we initialze each page struct is set as reserved upon initialization. This changes to starting with the reserved bit clear and then only setting the bit in the reserved region. Signed-off-by: Robin Holt h...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter

[RFC v3 3/5] Move page initialization into a separate function.

Holt h...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter Anvin h...@zytor.com To: Ingo Molnar mi...@kernel.org Cc: Linux Kernel linux-kernel@vger.kernel.org Cc: Linux MM linux...@kvack.org Cc: Rob Landley r...@landley.net Cc: Mike Travis tra...@sgi.com Cc: Daniel J Blueman dan

[RFC v3 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator

at moving the reserved bit. __expand_page_initialization should only be called by ensure_pages_are_initialized Nathan Zimmer (1): Only set page reserved in the memblock region Robin Holt (4): memblock: Introduce a for_each_reserved_mem_region iterator. Have __free_pages_memory() free

[RFC v3 5/5] Sparse initialization of struct page array.

. Besides the advantage of boot speed, this allows us the chance to use normal performance monitoring tools to determine where the bulk of time is spent during page initialization. Signed-off-by: Robin Holt h...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter Anvin h...@zytor.com

[RFC v3 2/5] Have __free_pages_memory() free in larger chunks.

that to be increased. We are increasing to the maximum size available. Signed-off-by: Robin Holt h...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter Anvin h...@zytor.com To: Ingo Molnar mi...@kernel.org Cc: Linux Kernel linux-kernel@vger.kernel.org Cc: Linux MM linux...@kvack.org Cc: Rob

Re: [RFC v2 4/5] Only set page reserved in the memblock region

On Fri, Aug 02, 2013 at 12:44:26PM -0500, Nathan Zimmer wrote: > Currently we when we initialze each page struct is set as reserved upon > initialization. This changes to starting with the reserved bit clear and > then only setting the bit in the reserved region. > > I could r

Re: [RFC v2 4/5] Only set page reserved in the memblock region

On Fri, Aug 02, 2013 at 12:44:26PM -0500, Nathan Zimmer wrote: Currently we when we initialze each page struct is set as reserved upon initialization. This changes to starting with the reserved bit clear and then only setting the bit in the reserved region. I could restruture a bit

[RFC v2 3/5] Move page initialization into a separate function.

-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc: Mel Gorman --- mm/mm_init.c| 2 +- mm/page_al

[RFC v2 4/5] Only set page reserved in the memblock region

. Signed-off-by: Robin Holt Signed-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc: Mel Gorman --- include/linux/mm.h | 2 ++ mm/n

[RFC v2 0/5] Transparent on-demand struct page initialization embedded in the buddy allocator

there are some still rough parts but I wanted to check in with the full patch set. Nathan Zimmer (1): Only set page reserved in the memblock region Robin Holt (4): memblock: Introduce a for_each_reserved_mem_region iterator. Have __free_pages_memory() free in larger chunks. Move page

[RFC v2 5/5] Sparse initialization of struct page array.

the advantage of boot speed, this allows us the chance to use normal performance monitoring tools to determine where the bulk of time is spent during page initialization. Signed-off-by: Robin Holt Signed-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux M

[RFC v2 1/5] memblock: Introduce a for_each_reserved_mem_region iterator.

Signed-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc: Mel Gorman --- include/linux/memblock.h | 18 ++ mm/

[RFC v2 2/5] Have __free_pages_memory() free in larger chunks.

are increasing to the maximum size available. Signed-off-by: Robin Holt Signed-off-by: Nathan Zimmer To: "H. Peter Anvin" To: Ingo Molnar Cc: Linux Kernel Cc: Linux MM Cc: Rob Landley Cc: Mike Travis Cc: Daniel J Blueman Cc: Andrew Morton Cc: Greg KH Cc: Yinghai Lu Cc:

[RFC v2 2/5] Have __free_pages_memory() free in larger chunks.

that to be increased. We are increasing to the maximum size available. Signed-off-by: Robin Holt h...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter Anvin h...@zytor.com To: Ingo Molnar mi...@kernel.org Cc: Linux Kernel linux-kernel@vger.kernel.org Cc: Linux MM linux...@kvack.org Cc: Rob

[RFC v2 1/5] memblock: Introduce a for_each_reserved_mem_region iterator.

-by: Robin Holt h...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter Anvin h...@zytor.com To: Ingo Molnar mi...@kernel.org Cc: Linux Kernel linux-kernel@vger.kernel.org Cc: Linux MM linux...@kvack.org Cc: Rob Landley r...@landley.net Cc: Mike Travis tra...@sgi.com Cc: Daniel J Blueman dan

[RFC v2 5/5] Sparse initialization of struct page array.

. Besides the advantage of boot speed, this allows us the chance to use normal performance monitoring tools to determine where the bulk of time is spent during page initialization. Signed-off-by: Robin Holt h...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter Anvin h...@zytor.com

[RFC v2 4/5] Only set page reserved in the memblock region

. Signed-off-by: Robin Holt h...@sgi.com Signed-off-by: Nathan Zimmer nzim...@sgi.com To: H. Peter Anvin h...@zytor.com To: Ingo Molnar mi...@kernel.org Cc: Linux Kernel linux-kernel@vger.kernel.org Cc: Linux MM linux...@kvack.org Cc: Rob Landley r...@landley.net Cc: Mike Travis tra...@sgi.com Cc

  1   2   3   4   >