On 06/16/2010 12:01 PM, Samuel Thibault wrote:
Ingo Molnar, le Wed 16 Jun 2010 10:39:41 +0200, a écrit :
in the long run most processes will be using the FPU due to SIMM
instructions.
I believe glibc already uses SIMM instructions for e.g. memcpy and
friends, i.e. basically all applic
On 06/16/2010 12:10 PM, Nick Piggin wrote:
This cannot be stated categorically without precise measurements of
known-good, known-bad, average FPU usage and average CPU usage scenarios. All
these workloads have different characteristics.
I can imagine bad effects across all sorts of workloads:
On 06/16/2010 11:39 AM, Ingo Molnar wrote:
(Cc:-ed various performance/optimization folks)
* Avi Kivity wrote:
On 06/16/2010 10:32 AM, H. Peter Anvin wrote:
On 06/16/2010 12:24 AM, Avi Kivity wrote:
Ingo, Peter, any feedback on this?
Conceptually, this makes sen
Ingo Molnar, le Wed 16 Jun 2010 10:39:41 +0200, a écrit :
> in the long run most processes will be using the FPU due to SIMM
> instructions.
I believe glibc already uses SIMM instructions for e.g. memcpy and
friends, i.e. basically all applications...
Samuel
--
To unsubscribe from this list
On Wed, Jun 16, 2010 at 10:39:41AM +0200, Ingo Molnar wrote:
>
> (Cc:-ed various performance/optimization folks)
>
> * Avi Kivity wrote:
>
> > On 06/16/2010 10:32 AM, H. Peter Anvin wrote:
> > >On 06/16/2010 12:24 AM, Avi Kivity wrote:
> > >>Ingo, Peter, any feedback on this?
> > > Conceptually
(Cc:-ed various performance/optimization folks)
* Avi Kivity wrote:
> On 06/16/2010 10:32 AM, H. Peter Anvin wrote:
> >On 06/16/2010 12:24 AM, Avi Kivity wrote:
> >>Ingo, Peter, any feedback on this?
> > Conceptually, this makes sense to me. However, I have a concern what
> > happens when a ta
On 06/16/2010 10:32 AM, H. Peter Anvin wrote:
On 06/16/2010 12:24 AM, Avi Kivity wrote:
Ingo, Peter, any feedback on this?
Conceptually, this makes sense to me. However, I have a concern what
happens when a task is scheduled on another CPU, while its FPU state is
still in registers i
On 06/16/2010 12:24 AM, Avi Kivity wrote:
>
> Ingo, Peter, any feedback on this?
>
Conceptually, this makes sense to me. However, I have a concern what
happens when a task is scheduled on another CPU, while its FPU state is
still in registers in the original CPU. That would seem to require
exp
On 06/13/2010 06:03 PM, Avi Kivity wrote:
Currently fpu management is only lazy in one direction. When we switch into
a task, we may avoid loading the fpu state in the hope that the task will
never use it. If we guess right we save an fpu load/save cycle; if not,
a Device not Available exceptio
On 06/13/2010 11:45 PM, valdis.kletni...@vt.edu wrote:
On Sun, 13 Jun 2010 18:03:43 +0300, Avi Kivity said:
Currently fpu management is only lazy in one direction. When we switch into
a task, we may avoid loading the fpu state in the hope that the task will
never use it. If we guess right
On Sun, 13 Jun 2010 18:03:43 +0300, Avi Kivity said:
> Currently fpu management is only lazy in one direction. When we switch into
> a task, we may avoid loading the fpu state in the hope that the task will
> never use it. If we guess right we save an fpu load/save cycle; if not,
> a Device not A
Currently fpu management is only lazy in one direction. When we switch into
a task, we may avoid loading the fpu state in the hope that the task will
never use it. If we guess right we save an fpu load/save cycle; if not,
a Device not Available exception will remind us to load the fpu.
However,
12 matches
Mail list logo
