From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3vtMh61M8KzDqGv for ; Wed, 29 Mar 2017 20:21:10 +1100 (AEDT) Received: by mail-pg0-x242.google.com with SMTP id 79so1949508pgf.0 for ; Wed, 29 Mar 2017 02:21:10 -0700 (PDT) Subject: Re: [PATCH V5 16/17] mm: Let arch choose the initial value of task size To: "Aneesh Kumar K.V" , benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au References: <1490153823-29241-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1490153823-29241-17-git-send-email-aneesh.kumar@linux.vnet.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org, "Kirill A . Shutemov" , linux-mm@kvack.org, Andrew Morton From: Anshuman Khandual Message-ID: <00df9abd-b023-0d1c-6753-654f682cd754@gmail.com> Date: Wed, 29 Mar 2017 14:50:51 +0530 MIME-Version: 1.0 In-Reply-To: <1490153823-29241-17-git-send-email-aneesh.kumar@linux.vnet.ibm.com> Content-Type: multipart/alternative; boundary="------------D1740DB1BDDFFECE9575679A" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------D1740DB1BDDFFECE9575679A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On Wednesday 22 March 2017 09:07 AM, Aneesh Kumar K.V wrote: > As we start supporting larger address space (>128TB), we want to give > architecture a control on max task size of an application which is different > from the TASK_SIZE. For ex: ppc64 needs to track the base page size of a segment > and it is copied from mm_context_t to PACA on each context switch. If we know that > application has not used an address range above 128TB we only need to copy > details about 128TB range to PACA. This will help in improving context switch > performance by avoiding larger copy operation. > > Cc: Kirill A. Shutemov > Cc: linux-mm@kvack.org > Cc: Andrew Morton > Signed-off-by: Aneesh Kumar K.V > --- > fs/exec.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/fs/exec.c b/fs/exec.c > index 65145a3df065..5550a56d03c3 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1308,6 +1308,14 @@ void would_dump(struct linux_binprm *bprm, struct file *file) > } > EXPORT_SYMBOL(would_dump); > > +#ifndef arch_init_task_size > +static inline void arch_init_task_size(void) > +{ > + current->mm->task_size = TASK_SIZE; > +} > +#define arch_init_task_size arch_init_task_size > +#endif Why not a proper CONFIG_ARCH_DEFINED_TASK_SIZE kind of option for this ? Also are there no assumptions about task current->mm->size being TASK_SIZE in other places which might get broken ? --------------D1740DB1BDDFFECE9575679A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

On Wednesday 22 March 2017 09:07 AM, Aneesh Kumar K.V wrote:

As we start supporting larger address space (>128TB), we want to give
architecture a control on max task size of an application which is different
from the TASK_SIZE. For ex: ppc64 needs to track the base page size of a segment
and it is copied from mm_context_t to PACA on each context switch. If we know that
application has not used an address range above 128TB we only need to copy
details about 128TB range to PACA. This will help in improving context switch
performance by avoiding larger copy operation.

Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
 fs/exec.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/fs/exec.c b/fs/exec.c
index 65145a3df065..5550a56d03c3 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1308,6 +1308,14 @@ void would_dump(struct linux_binprm *bprm, struct file *file)
 }
 EXPORT_SYMBOL(would_dump);

+#ifndef arch_init_task_size
+static inline void arch_init_task_size(void)
+{
+	current->mm->task_size = TASK_SIZE;
+}
+#define arch_init_task_size arch_init_task_size
+#endif

Why not a proper CONFIG_ARCH_DEFINED_TASK_SIZE kind of option for this ? Also
are there no assumptions about task current->mm->size being TASK_SIZE in other
places which might get broken ?
--------------D1740DB1BDDFFECE9575679A--