On Thu, 2014-05-15 at 02:05 -0400, Tejun Heo wrote:
> I'm not sure how much weight I can put on the specific use case. Even
> with the direct control that the user thought to have previously, the
> use case was ripe with possibilities of breakage from any number of
> reasons. For example, there
Hello, Mike.
On Thu, May 15, 2014 at 07:32:29AM +0200, Mike Galbraith wrote:
> On Thu, 2014-05-15 at 01:09 -0400, Tejun Heo wrote:
> > > Soft/hard irq threads and anything having to do with IO mostly, which
> > > including workqueues. I had to give the user a rather fugly global
> > > prioritiza
On Thu, 2014-05-15 at 01:09 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Thu, May 15, 2014 at 07:04:22AM +0200, Mike Galbraith wrote:
> > On Thu, 2014-05-15 at 00:50 -0400, Tejun Heo wrote:
> > > Do we know specific kthreads which need to be exposed with this way?
> >
> > Soft/hard irq threads
Hello, Mike.
On Thu, May 15, 2014 at 07:04:22AM +0200, Mike Galbraith wrote:
> On Thu, 2014-05-15 at 00:50 -0400, Tejun Heo wrote:
> > Do we know specific kthreads which need to be exposed with this way?
>
> Soft/hard irq threads and anything having to do with IO mostly, which
> including workqu
On Thu, 2014-05-15 at 00:50 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Thu, May 15, 2014 at 06:46:18AM +0200, Mike Galbraith wrote:
> > > I think it'd be healthier to identify the use cases and then provide
> > > proper interface for it. Note that workqueue can now expose interface
> > > to m
Hello, Mike.
On Thu, May 15, 2014 at 06:46:18AM +0200, Mike Galbraith wrote:
> > I think it'd be healthier to identify the use cases and then provide
> > proper interface for it. Note that workqueue can now expose interface
> > to modify concurrency, priority and cpumask to userland which
> > wri
On Thu, 2014-05-15 at 00:06 -0400, Tejun Heo wrote:
> Hey, Mike.
>
> On Thu, May 15, 2014 at 05:53:57AM +0200, Mike Galbraith wrote:
> > Hm. The user would need to be able to identify and prioritize the
>
> I suppose you mean userland by "the user"?
Yeah.
> > things, and have his settings sti
Hey, Mike.
On Thu, May 15, 2014 at 05:53:57AM +0200, Mike Galbraith wrote:
> Hm. The user would need to be able to identify and prioritize the
I suppose you mean userland by "the user"?
> things, and have his settings stick. Any dynamic pool business doing
> allocations and/or munging prioriti
On Wed, 2014-05-14 at 12:32 -0400, Tejun Heo wrote:
> Hello, Jiri, Vojtech.
>
> On Wed, May 14, 2014 at 05:15:01PM +0200, Vojtech Pavlik wrote:
> > On Wed, May 14, 2014 at 04:59:05PM +0200, Jiri Slaby wrote:
> > > I see the worst case scenario. (For curious readers, it is for example
> > > this k
Hello, Jiri, Vojtech.
On Wed, May 14, 2014 at 05:15:01PM +0200, Vojtech Pavlik wrote:
> On Wed, May 14, 2014 at 04:59:05PM +0200, Jiri Slaby wrote:
> > I see the worst case scenario. (For curious readers, it is for example
> > this kthread body:
> > while (1) {
> > some_paired_call(); /* invokes
On Wed, May 14, 2014 at 05:15:01PM +0200, Vojtech Pavlik wrote:
> On Wed, May 14, 2014 at 04:59:05PM +0200, Jiri Slaby wrote:
>
> > I see the worst case scenario. (For curious readers, it is for example
> > this kthread body:
> > while (1) {
> > some_paired_call(); /* invokes pre-patched code */
On Wed, May 14, 2014 at 04:59:05PM +0200, Jiri Slaby wrote:
> I see the worst case scenario. (For curious readers, it is for example
> this kthread body:
> while (1) {
> some_paired_call(); /* invokes pre-patched code */
> if (kthread_should_stop()) { /* kgraft switches to the new code */
>
Hi Tejun,
On 05/01/2014 11:09 PM, Tejun Heo wrote:
> On Thu, May 01, 2014 at 05:02:42PM -0400, Tejun Heo wrote:
>> Hello, Jiri.
>>
>> On Thu, May 01, 2014 at 10:17:44PM +0200, Jiri Kosina wrote:
>>> I agree that this expectation might really somewhat implicit and is not
>>> probably properly docu
On Thu, May 01, 2014 at 05:02:42PM -0400, Tejun Heo wrote:
> Hello, Jiri.
>
> On Thu, May 01, 2014 at 10:17:44PM +0200, Jiri Kosina wrote:
> > I agree that this expectation might really somewhat implicit and is not
> > probably properly documented anywhere. The basic observation is "whenever
> >
Hello, Jiri.
On Thu, May 01, 2014 at 10:17:44PM +0200, Jiri Kosina wrote:
> I agree that this expectation might really somewhat implicit and is not
> probably properly documented anywhere. The basic observation is "whenever
> kthread_should_stop() is being called, all data structures are in a
>
On Thu, 1 May 2014, Tejun Heo wrote:
> > Some threads do not use kthread_should_stop. Before we enable a
>
> Haven't really following kgraft development but is it safe to assume
> that all kthread_should_stop() usages are clean side-effect-less
> boundaries? If so, why is that property guarantee
On Wed, Apr 30, 2014 at 04:30:42PM +0200, Jiri Slaby wrote:
> Some threads do not use kthread_should_stop. Before we enable a
Haven't really following kgraft development but is it safe to assume
that all kthread_should_stop() usages are clean side-effect-less
boundaries? If so, why is that proper
On Wed, Apr 30, 2014 at 08:33:27PM +0200, Vojtech Pavlik wrote:
> On Wed, Apr 30, 2014 at 09:55:32AM -0700, Paul E. McKenney wrote:
> > On Wed, Apr 30, 2014 at 04:30:42PM +0200, Jiri Slaby wrote:
> > > Some threads do not use kthread_should_stop. Before we enable a
> > > kthread support in kgr, we
On Wed, Apr 30, 2014 at 09:55:32AM -0700, Paul E. McKenney wrote:
> On Wed, Apr 30, 2014 at 04:30:42PM +0200, Jiri Slaby wrote:
> > Some threads do not use kthread_should_stop. Before we enable a
> > kthread support in kgr, we must make sure all those mark themselves
> > safe explicitly.
>
> Would
On Wed, Apr 30, 2014 at 04:30:42PM +0200, Jiri Slaby wrote:
> Some threads do not use kthread_should_stop. Before we enable a
> kthread support in kgr, we must make sure all those mark themselves
> safe explicitly.
Would it make sense to bury kgr_task_safe() in wait_event_interruptible()
and frien
On Wed, Apr 30, 2014 at 04:30:42PM +0200, Jiri Slaby wrote:
> Some threads do not use kthread_should_stop. Before we enable a
> kthread support in kgr, we must make sure all those mark themselves
> safe explicitly.
>
> Signed-off-by: Jiri Slaby
> Cc: Steven Rostedt
> Cc: Frederic Weisbecker
> C
Some threads do not use kthread_should_stop. Before we enable a
kthread support in kgr, we must make sure all those mark themselves
safe explicitly.
Signed-off-by: Jiri Slaby
Cc: Steven Rostedt
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Greg Kroah-Hartman
Cc: "Theodore Ts'o"
Cc: Dipankar Sa
22 matches
Mail list logo
