All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Khalid Aziz <khalid.aziz@oracle.com>
Cc: tglx@linutronix.de, corbet@lwn.net, mingo@redhat.com,
	hpa@zytor.com, peterz@infradead.org, riel@redhat.com,
	akpm@linux-foundation.org, rientjes@google.com, mgorman@suse.de,
	liwanp@linux.vnet.ibm.com, raistlin@linux.it,
	kirill.shutemov@linux.intel.com, atomlin@redhat.com,
	avagin@openvz.org, gorcunov@openvz.org,
	serge.hallyn@canonical.com, athorlton@sgi.com, oleg@redhat.com,
	vdavydov@parallels.com, daeseok.youn@gmail.com,
	keescook@chromium.org, yangds.fnst@cn.fujitsu.com,
	sbauer@eng.utah.edu, vishnu.ps@samsung.com, axboe@fb.com,
	paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice (was: Pre-emption control for userspace)
Date: Mon, 24 Nov 2014 14:43:02 -0800	[thread overview]
Message-ID: <20141124224302.GL10824@tassilo.jf.intel.com> (raw)
In-Reply-To: <1416862595-24513-1-git-send-email-khalid.aziz@oracle.com>

> +1. Location of shared flag can be set using prctl() only once. To
> +   write a new memory address, the previous memory address must be
> +   cleared first by writing NULL. Each new memory address requires
> +   validation in the kernel and update of pointers. Changing this
> +   address too many times creates too much overhead.

Can you explain this more? Doesn't make any sense to me.
The validation is just access_ok() which is only a few instructions?

Also I would drop the config symbol. Linux normally doesn't
do CONFIG for things like that.

> diff --git a/kernel/fork.c b/kernel/fork.c
> index 9b7d746..7f0d843 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1671,6 +1671,11 @@ long do_fork(unsigned long clone_flags,
>  			init_completion(&vfork);
>  			get_task_struct(p);
>  		}
> +#ifdef CONFIG_SCHED_PREEMPT_DELAY
> +		p->sched_preempt_delay.delay_req = NULL;
> +		p->sched_preempt_delay.delay_granted = 0;
> +		p->sched_preempt_delay.yield_penalty = 0;
> +#endif

FWIW this would lead to every new thread having to reexecute
this. No good way around it, but it may eventually make
thread spawns more expensive if it was widely used.

>  
> +#ifdef CONFIG_SCHED_PREEMPT_DELAY
> +	/*
> +	 * Clear the penalty flag for current task to reward it for
> +	 * palying by the rules
> +	 */
> +	current->sched_preempt_delay.yield_penalty = 0;
> +#endif

Doesn't that need to be quantified? After all they may yield
only near the end of their time slice.

> +	}
> +
> +	/*
> +	 * Get the value of preemption delay request flag from userspace.
> +	 * Task had already passed us the address where the flag is stored
> +	 * in userspace earlier. This flag is just like the PROCESS_PRIVATE
> +	 * futex, leverage the futex code here to read the flag. If there

I don't think any of the calls below are futex code.

> +	case PR_GET_PREEMPT_DELAY:
> +		error = put_user(
> +			(unsigned long)current->sched_preempt_delay.delay_req,
> +					(unsigned long __user *)arg2);
> +		break;
> +#endif

Unnecessary cast.

> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1104,6 +1104,15 @@ static struct ctl_table kern_table[] = {
>  		.proc_handler	= proc_dointvec,
>  	},
>  #endif
> +#ifdef CONFIG_SCHED_PREEMPT_DELAY
> +	{
> +		.procname	= "preempt_delay_available",
> +		.data		= &sysctl_preempt_delay_available,
> +		.maxlen		= sizeof(int),
> +		.mode		= 0600,

Better 0644, so users can know if they can use it.

Rest looks reasonable to me.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only

  reply	other threads:[~2014-11-24 22:43 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-24 20:56 [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice (was: Pre-emption control for userspace) Khalid Aziz
2014-11-24 22:43 ` Andi Kleen [this message]
     [not found]   ` <20141124224302.GL10824-KWJ+5VKanrL29G5dvP0v1laTQe2KTcn/@public.gmane.org>
2014-11-24 23:20     ` Khalid Aziz
2014-11-24 23:20       ` Khalid Aziz
2014-11-24 23:35 ` Thomas Gleixner
2014-11-25  2:12   ` Davidlohr Bueso
2014-11-25  2:12     ` Davidlohr Bueso
2014-11-25  4:20   ` Mike Galbraith
     [not found]     ` <1416889208.4335.127.camel-sZ+7a5bGyC/1wTEvPJ5Q0F6hYfS7NtTn@public.gmane.org>
2014-11-25 14:50       ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice Khalid Aziz
2014-11-25 14:50         ` Khalid Aziz
2014-11-25 17:46         ` Mike Galbraith
     [not found]           ` <1416937564.3512.15.camel-sZ+7a5bGyC/1wTEvPJ5Q0F6hYfS7NtTn@public.gmane.org>
2014-11-25 19:38             ` Khalid Aziz
2014-11-25 19:38               ` Khalid Aziz
2014-11-25 14:45   ` Khalid Aziz
     [not found]     ` <54749617.5030309-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-11-25 18:27       ` Davidlohr Bueso
2014-11-25 18:27         ` Davidlohr Bueso
2014-11-25 19:23         ` Khalid Aziz
     [not found]           ` <5474D71E.8070603-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-11-25 19:40             ` Davidlohr Bueso
2014-11-25 19:40               ` Davidlohr Bueso
2014-11-25  2:03 ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice (was: Pre-emption control for userspace) Rik van Riel
2014-11-25  6:30   ` Davidlohr Bueso
2014-11-25 13:38     ` Rik van Riel
2014-11-25 14:52   ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice Khalid Aziz
2014-11-25 15:25     ` Rik van Riel
     [not found]       ` <54749F77.50905-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-11-25 17:22         ` Khalid Aziz
2014-11-25 17:22           ` Khalid Aziz
2014-11-25 17:45           ` Rik van Riel
     [not found] ` <1416862595-24513-1-git-send-email-khalid.aziz-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-11-25 10:12   ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice (was: Pre-emption control for userspace) Srikar Dronamraju
2014-11-25 10:12     ` Srikar Dronamraju
2014-11-25 14:56     ` [PATCH v3] sched/fair: Add advisory flag for borrowing a timeslice Khalid Aziz

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=20141124224302.GL10824@tassilo.jf.intel.com \
    --to=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=athorlton@sgi.com \
    --cc=atomlin@redhat.com \
    --cc=avagin@openvz.org \
    --cc=axboe@fb.com \
    --cc=corbet@lwn.net \
    --cc=daeseok.youn@gmail.com \
    --cc=gorcunov@openvz.org \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=khalid.aziz@oracle.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liwanp@linux.vnet.ibm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=raistlin@linux.it \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=sbauer@eng.utah.edu \
    --cc=serge.hallyn@canonical.com \
    --cc=tglx@linutronix.de \
    --cc=vdavydov@parallels.com \
    --cc=vishnu.ps@samsung.com \
    --cc=yangds.fnst@cn.fujitsu.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.