public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Jack Steiner <steiner@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH]  Reduce TLB flushing during process migration
Date: Tue, 01 Jun 2004 15:59:52 +0000	[thread overview]
Message-ID: <20040601155952.GA2491@sgi.com> (raw)
In-Reply-To: <20040522121159.GB19454@sgi.com>

> > 
> > But I don't understand why your patch adds two flush_tlb_mm() calls into
> > sched.c on ia32 where there previously was no such call.
> 
> I thought I had a good reason. Let me check & make sure I didnt overlook
> something. I'll get back to you.....
> 

You are right - the second call is not needed. I wanted to clear
cpu_vm_mask after an exec migration. That is not required because
exec calls init_new_context() shortly after the migrate anyway.



However, I found an unrelated issue.
It looks like the call to sched_balance_exec() from do_execve()
is in the wrong spot.


	int do_execve(char * filename,
        	char __user *__user *argv,
        	char __user *__user *envp,
        	struct pt_regs * regs)
	{
        	struct linux_binprm bprm;
        	struct file *file;
        	int retval;
        	int i;
	
        	sched_balance_exec();
	
        	file = open_exec(filename);
	
        	retval = PTR_ERR(file);
        	if (IS_ERR(file))
                	return retval;
	
        	bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
		...



The code calls sched_balance_exec() before determining whether "filename"
actually exists. 

In many cases, users have several entries in $PATH.
If a full path name is not specified on the 'exec" call, the library 
code iterates thru the files in the PATH list until it finds the program. This
can result is numerous migrations of the parent process before
the program is actually found.


Shouldn't the call to sched_balance_exec() be moved to just before "bprm...."
or am I overlooking something?




--- linuxbase/fs/exec.c	2004-05-21 20:47:27.000000000 -0500
+++ linux/fs/exec.c	2004-06-01 10:46:35.000000000 -0500
@@ -1083,14 +1083,14 @@
 	int retval;
 	int i;
 
-	sched_balance_exec();
-
 	file = open_exec(filename);
 
 	retval = PTR_ERR(file);
 	if (IS_ERR(file))
 		return retval;
 
+	sched_balance_exec();
+
 	bprm.p = PAGE_SIZE*MAX_ARG_PAGES-sizeof(void *);
 	memset(bprm.page, 0, MAX_ARG_PAGES*sizeof(bprm.page[0]));
 



-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.



      parent reply	other threads:[~2004-06-01 15:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-22 12:11 [PATCH] Reduce TLB flushing during process migration Jack Steiner
2004-05-25  5:26 ` Andrew Morton
2004-05-25 13:45 ` Jack Steiner
2004-06-01 15:59 ` Jack Steiner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040601155952.GA2491@sgi.com \
    --to=steiner@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox