All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Rik van Riel <riel@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Yu-cheng Yu <yu-cheng.yu@intel.com>
Subject: Re: [PATCH 1/7] x86/fpu: Simplify the fpu->last_cpu logic and rename it to fpu->fpregs_cached
Date: Thu, 26 Jan 2017 16:09:55 +0100	[thread overview]
Message-ID: <20170126150955.GA12274@gmail.com> (raw)
In-Reply-To: <1485442458.15964.50.camel@redhat.com>


* Rik van Riel <riel@redhat.com> wrote:

> On Thu, 2017-01-26 at 12:26 +0100, Ingo Molnar wrote:
> 
> > index c56fb57f2991..7eb2f3041fde 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -1253,6 +1253,8 @@ void set_task_cpu(struct task_struct *p,
> > unsigned int new_cpu)
> >  			p->sched_class->migrate_task_rq(p);
> >  		p->se.nr_migrations++;
> >  		perf_event_task_migrate(p);
> > +
> > +		arch_task_migrate(p);
> >  	}
> > 
> 
> Does it really count as a "simplification" if you add a
> scheduler callback?
> 
> This code does not seem any easier to understand than
> the old code...

See the extra commit I added on top:

  7deff4369276 x86/fpu: Unify the naming of the FPU register cache validity flags

which makes it clearer, we now have:
	
	->fpregs_owner             [bool]
          fpregs_owner_ctx         [ptr]

That are set to 1 and the context pointer when a task with no FPU state is 
scheduled in and where the state of the previous task is preserved (cached) in the 
FPU registers - and which FPU register state cache can be invalidated after this 
by clearing any of the two flags.

That should make its overall meaning clearer, in that they represent a single 
'cache' where the cache validity flag is split into two copies, where any of which 
can be used to invalidate the cache.

Thanks,

	Ingo

  reply	other threads:[~2017-01-26 15:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-26 11:26 [PATCH 0/7] x86/fpu: Simplify the FPU state machine Ingo Molnar
2017-01-26 11:26 ` [PATCH 1/7] x86/fpu: Simplify the fpu->last_cpu logic and rename it to fpu->fpregs_cached Ingo Molnar
2017-01-26 14:23   ` Rik van Riel
2017-01-26 14:53     ` Ingo Molnar
2017-01-26 15:05       ` [PATCH] x86/fpu: Unify the naming of the FPU register cache validity flags Ingo Molnar
2017-01-26 15:31         ` Peter Zijlstra
2017-01-26 14:54   ` [PATCH 1/7] x86/fpu: Simplify the fpu->last_cpu logic and rename it to fpu->fpregs_cached Rik van Riel
2017-01-26 15:09     ` Ingo Molnar [this message]
2017-01-26 16:51     ` Andy Lutomirski
2017-01-26 11:26 ` [PATCH 2/7] x86/fpu: Simplify fpu->fpregs_active use Ingo Molnar
2017-01-26 16:30   ` Andy Lutomirski
2017-01-26 11:26 ` [PATCH 3/7] x86/fpu: Make the fpu state change in fpu__clear() scheduler-atomic Ingo Molnar
2017-01-26 11:26 ` [PATCH 4/7] x86/fpu: Split the state handling in fpu__drop() Ingo Molnar
2017-01-26 11:26 ` [PATCH 5/7] x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active Ingo Molnar
2017-01-26 14:44   ` Rik van Riel
2017-01-26 15:16     ` Ingo Molnar
2017-01-26 15:45       ` Rik van Riel
2017-01-26 15:53         ` Ingo Molnar
2017-01-26 17:00           ` Andy Lutomirski
2017-01-26 18:04             ` Rik van Riel
2017-01-26 11:26 ` [PATCH 6/7] x86/fpu: Decouple fpregs_activate()/fpregs_deactivate() from fpu->fpregs_active Ingo Molnar
2017-01-26 11:26 ` [PATCH 7/7] x86/fpu: Remove struct fpu::fpregs_active Ingo Molnar

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=20170126150955.GA12274@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yu-cheng.yu@intel.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.