On Tue, Apr 21, 2015 at 11:50:27AM -0400, Steven Rostedt wrote:
> On Tue, 21 Apr 2015 08:01:22 -0700
> "Paul E. McKenney" wrote:
>
> > > > Seem reasonable?
> > >
> > > Does chrt override the kthread_prio at run time? If so, then great.
> > > Otherwise, the sysadmin should still have a way to
On Tue, 21 Apr 2015 08:01:22 -0700
"Paul E. McKenney" wrote:
> > > Seem reasonable?
> >
> > Does chrt override the kthread_prio at run time? If so, then great.
> > Otherwise, the sysadmin should still have a way to control their
> > priorities of kernel threads (with few exceptions like the
On Tue, Apr 21, 2015 at 09:12:32AM -0400, Steven Rostedt wrote:
> On Mon, 20 Apr 2015 18:22:58 -0700
> "Paul E. McKenney" wrote:
>
> > On Mon, Apr 20, 2015 at 04:50:07PM -0500, Clark Williams wrote:
> > > On Mon, 20 Apr 2015 14:15:04 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > On Mon,
On Tue, 21 Apr 2015 08:42:23 +0200
Ingo Molnar wrote:
> Note that modern scheduler policies, like SCHED_DEADLINE, get all
> their policy parameters from the sched_setparam() user-space ABI, they
> are not driven by sysctls.
Right, and when I realized that we can do the same with chrt, I
On Mon, 20 Apr 2015 18:22:58 -0700
"Paul E. McKenney" wrote:
> On Mon, Apr 20, 2015 at 04:50:07PM -0500, Clark Williams wrote:
> > On Mon, 20 Apr 2015 14:15:04 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Mon, Apr 20, 2015 at 04:40:49PM -0400, Steven Rostedt wrote:
> > > > On Mon, Apr 20,
* Steven Rostedt wrote:
> On Mon, 20 Apr 2015 20:28:32 +0200
> Ingo Molnar wrote:
>
> > Instrumentation - especially instrumentation that should have been
> > implemented mostly in user-space, like ftrace ;-) - is another special
> > case that should stay as flexible as possible via
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, 20 Apr 2015 20:28:32 +0200
Ingo Molnar mi...@kernel.org wrote:
Instrumentation - especially instrumentation that should have been
implemented mostly in user-space, like ftrace ;-) - is another special
case that should stay as
On Mon, 20 Apr 2015 18:22:58 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Mon, Apr 20, 2015 at 04:50:07PM -0500, Clark Williams wrote:
On Mon, 20 Apr 2015 14:15:04 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Mon, Apr 20, 2015 at 04:40:49PM -0400, Steven
On Tue, 21 Apr 2015 08:42:23 +0200
Ingo Molnar mi...@kernel.org wrote:
Note that modern scheduler policies, like SCHED_DEADLINE, get all
their policy parameters from the sched_setparam() user-space ABI, they
are not driven by sysctls.
Right, and when I realized that we can do the same with
On Tue, Apr 21, 2015 at 09:12:32AM -0400, Steven Rostedt wrote:
On Mon, 20 Apr 2015 18:22:58 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Mon, Apr 20, 2015 at 04:50:07PM -0500, Clark Williams wrote:
On Mon, 20 Apr 2015 14:15:04 -0700
Paul E. McKenney
On Tue, 21 Apr 2015 08:01:22 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Seem reasonable?
Does chrt override the kthread_prio at run time? If so, then great.
Otherwise, the sysadmin should still have a way to control their
priorities of kernel threads (with few exceptions
On Tue, Apr 21, 2015 at 11:50:27AM -0400, Steven Rostedt wrote:
On Tue, 21 Apr 2015 08:01:22 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Seem reasonable?
Does chrt override the kthread_prio at run time? If so, then great.
Otherwise, the sysadmin should still have a
On Mon, 2015-04-20 at 14:21 -0400, Steven Rostedt wrote:
>
> I would argue than every case is different, and only the sysadmin
> would
> know the right value. Thus, just set it to one, and if that's not
> good
> enough, then the sysadmins can change it to their needs.
Agreed. I don't have it
On Mon, Apr 20, 2015 at 04:50:07PM -0500, Clark Williams wrote:
> On Mon, 20 Apr 2015 14:15:04 -0700
> "Paul E. McKenney" wrote:
>
> > On Mon, Apr 20, 2015 at 04:40:49PM -0400, Steven Rostedt wrote:
> > > On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
> > > >
> > > > The
On Mon, 20 Apr 2015 14:15:04 -0700
"Paul E. McKenney" wrote:
> On Mon, Apr 20, 2015 at 04:40:49PM -0400, Steven Rostedt wrote:
> > On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
> > >
> > > The sysfs knob might be nice, but as far as I know nobody has been
> > > complaining
On Mon, Apr 20, 2015 at 04:40:49PM -0400, Steven Rostedt wrote:
> On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
> >
> > The sysfs knob might be nice, but as far as I know nobody has been
> > complaining about it.
> >
> > Besides, we already have the rcutree.kthread_prio=
On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
>
> The sysfs knob might be nice, but as far as I know nobody has been
> complaining about it.
>
> Besides, we already have the rcutree.kthread_prio= kernel-boot parameter.
> So how about if the Kconfig parameter selects either
On Mon, 20 Apr 2015 20:28:32 +0200
Ingo Molnar wrote:
> Instrumentation - especially instrumentation that should have been
> implemented mostly in user-space, like ftrace ;-) - is another special
> case that should stay as flexible as possible via sysctls, obviously.
I know I used ftrace as
* Steven Rostedt wrote:
> On Mon, 20 Apr 2015 20:09:04 +0200
> Ingo Molnar wrote:
>
>
> > So the disadvantage is that if a boot default is wrong, we'll hear
> > about it eventually and can fix/improve it.
> >
> > If a sysctl knob is wrong, people will just 'tune' it and forget
> > to
On 04/20/2015 02:59 PM, Clark Williams wrote:
>> > That said, if the lack of a sysfs knob has been causing real problems,
>> > let's make that happen.
> I'll talk to the other RT-ers and get back to you on that. I suspect
> most folks would like it just to not have to reboot while tuning, but
>
On Mon, 20 Apr 2015 20:09:04 +0200
Ingo Molnar wrote:
> So the disadvantage is that if a boot default is wrong, we'll hear
> about it eventually and can fix/improve it.
>
> If a sysctl knob is wrong, people will just 'tune' it and forget to
> propagate it to the kernel proper (why should
* Steven Rostedt wrote:
> On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
> >
> > The sysfs knob might be nice, but as far as I know nobody has been
> > complaining about it.
> >
> > Besides, we already have the rcutree.kthread_prio= kernel-boot
> > parameter. So how about
On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
>
> The sysfs knob might be nice, but as far as I know nobody has been
> complaining about it.
>
> Besides, we already have the rcutree.kthread_prio= kernel-boot parameter.
> So how about if the Kconfig parameter selects either
On Mon, 20 Apr 2015 10:09:03 -0700
"Paul E. McKenney" wrote:
> On Mon, Apr 20, 2015 at 11:35:54AM -0500, Clark Williams wrote:
> > On Sat, 18 Apr 2015 19:05:42 -0700
> > "Paul E. McKenney" wrote:
> > > > > > Real-time priority to use for RCU worker threads
> > > > > > (RCU_KTHREAD_PRIO)
On Mon, Apr 20, 2015 at 11:35:54AM -0500, Clark Williams wrote:
> On Sat, 18 Apr 2015 19:05:42 -0700
> "Paul E. McKenney" wrote:
> > > > > Real-time priority to use for RCU worker threads
> > > > > (RCU_KTHREAD_PRIO) [0] (NEW)
> > > >
> > > > Indeed, Linus complained about this one. ;-)
On Sat, 18 Apr 2015 19:05:42 -0700
"Paul E. McKenney" wrote:
> > > > Real-time priority to use for RCU worker threads
> > > > (RCU_KTHREAD_PRIO) [0] (NEW)
> > >
> > > Indeed, Linus complained about this one. ;-)
> >
> > :-) Yes, it's an essentially unanswerable question.
> >
> > >
On Mon, 20 Apr 2015 14:15:04 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Mon, Apr 20, 2015 at 04:40:49PM -0400, Steven Rostedt wrote:
On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
The sysfs knob might be nice, but as far as I know nobody has been
On Mon, Apr 20, 2015 at 04:50:07PM -0500, Clark Williams wrote:
On Mon, 20 Apr 2015 14:15:04 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Mon, Apr 20, 2015 at 04:40:49PM -0400, Steven Rostedt wrote:
On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
The sysfs knob might be nice, but as far as I know nobody has been
complaining about it.
Besides, we already have the rcutree.kthread_prio= kernel-boot parameter.
So how about if the Kconfig parameter selects either
On Mon, Apr 20, 2015 at 04:40:49PM -0400, Steven Rostedt wrote:
On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
The sysfs knob might be nice, but as far as I know nobody has been
complaining about it.
Besides, we already have the rcutree.kthread_prio= kernel-boot
On Mon, 2015-04-20 at 14:21 -0400, Steven Rostedt wrote:
I would argue than every case is different, and only the sysadmin
would
know the right value. Thus, just set it to one, and if that's not
good
enough, then the sysadmins can change it to their needs.
Agreed. I don't have it turned
On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
The sysfs knob might be nice, but as far as I know nobody has been
complaining about it.
Besides, we already have the rcutree.kthread_prio= kernel-boot parameter.
So how about if the Kconfig parameter selects either
On Mon, 20 Apr 2015 20:09:04 +0200
Ingo Molnar mi...@kernel.org wrote:
So the disadvantage is that if a boot default is wrong, we'll hear
about it eventually and can fix/improve it.
If a sysctl knob is wrong, people will just 'tune' it and forget to
propagate it to the kernel proper (why
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, Apr 20, 2015 at 10:09:03AM -0700, Paul E. McKenney wrote:
The sysfs knob might be nice, but as far as I know nobody has been
complaining about it.
Besides, we already have the rcutree.kthread_prio= kernel-boot
parameter. So how
On Sat, 18 Apr 2015 19:05:42 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Real-time priority to use for RCU worker threads
(RCU_KTHREAD_PRIO) [0] (NEW)
Indeed, Linus complained about this one. ;-)
:-) Yes, it's an essentially unanswerable question.
On Mon, 20 Apr 2015 10:09:03 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Mon, Apr 20, 2015 at 11:35:54AM -0500, Clark Williams wrote:
On Sat, 18 Apr 2015 19:05:42 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Real-time priority to use for RCU worker
On Mon, Apr 20, 2015 at 11:35:54AM -0500, Clark Williams wrote:
On Sat, 18 Apr 2015 19:05:42 -0700
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Real-time priority to use for RCU worker threads
(RCU_KTHREAD_PRIO) [0] (NEW)
Indeed, Linus complained about this one.
On 04/20/2015 02:59 PM, Clark Williams wrote:
That said, if the lack of a sysfs knob has been causing real problems,
let's make that happen.
I'll talk to the other RT-ers and get back to you on that. I suspect
most folks would like it just to not have to reboot while tuning, but
not sure
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, 20 Apr 2015 20:09:04 +0200
Ingo Molnar mi...@kernel.org wrote:
So the disadvantage is that if a boot default is wrong, we'll hear
about it eventually and can fix/improve it.
If a sysctl knob is wrong, people will just 'tune' it
On Mon, 20 Apr 2015 20:28:32 +0200
Ingo Molnar mi...@kernel.org wrote:
Instrumentation - especially instrumentation that should have been
implemented mostly in user-space, like ftrace ;-) - is another special
case that should stay as flexible as possible via sysctls, obviously.
I know I
On Sat, Apr 18, 2015 at 04:32:38PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Sat, Apr 18, 2015 at 03:03:41PM +0200, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney wrote:
> > >
> > > > Hello, Ingo,
> > > >
> > > > This series contains a single change that fixes
* Paul E. McKenney wrote:
> On Sat, Apr 18, 2015 at 03:03:41PM +0200, Ingo Molnar wrote:
> >
> > * Paul E. McKenney wrote:
> >
> > > Hello, Ingo,
> > >
> > > This series contains a single change that fixes Kconfig asking pointless
> > > questions (https://lkml.org/lkml/2015/4/14/616). This
On Sat, Apr 18, 2015 at 03:03:41PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > Hello, Ingo,
> >
> > This series contains a single change that fixes Kconfig asking pointless
> > questions (https://lkml.org/lkml/2015/4/14/616). This is an RFC pull
> > because there has not yet
* Paul E. McKenney wrote:
> Hello, Ingo,
>
> This series contains a single change that fixes Kconfig asking pointless
> questions (https://lkml.org/lkml/2015/4/14/616). This is an RFC pull
> because there has not yet been a -next build for April 16th. If you
> would prefer to wait until
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Sat, Apr 18, 2015 at 03:03:41PM +0200, Ingo Molnar wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Hello, Ingo,
This series contains a single change that fixes Kconfig asking pointless
questions
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Hello, Ingo,
This series contains a single change that fixes Kconfig asking pointless
questions (https://lkml.org/lkml/2015/4/14/616). This is an RFC pull
because there has not yet been a -next build for April 16th. If you
would
On Sat, Apr 18, 2015 at 03:03:41PM +0200, Ingo Molnar wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Hello, Ingo,
This series contains a single change that fixes Kconfig asking pointless
questions (https://lkml.org/lkml/2015/4/14/616). This is an RFC pull
because
On Sat, Apr 18, 2015 at 04:32:38PM +0200, Ingo Molnar wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Sat, Apr 18, 2015 at 03:03:41PM +0200, Ingo Molnar wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Hello, Ingo,
This series contains a
Hello, Ingo,
This series contains a single change that fixes Kconfig asking pointless
questions (https://lkml.org/lkml/2015/4/14/616). This is an RFC pull
because there has not yet been a -next build for April 16th. If you
would prefer to wait until after -next has pulled this, please let me
Hello, Ingo,
This series contains a single change that fixes Kconfig asking pointless
questions (https://lkml.org/lkml/2015/4/14/616). This is an RFC pull
because there has not yet been a -next build for April 16th. If you
would prefer to wait until after -next has pulled this, please let me
50 matches
Mail list logo
