public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Avi Kivity <avi@qumranet.com>, Agner Fog <agner@agner.org>,
	Arjan van de Ven <arjan@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: ABI change for device drivers using future AVX instruction set
Date: Sun, 29 Jun 2008 15:08:22 -0700	[thread overview]
Message-ID: <486807D6.9060407@zytor.com> (raw)
In-Reply-To: <48678CC5.5080504@firstfloor.org>

Andi Kleen wrote:
>>>   
>> If you use xsave, I don't see how this is different to the user fpu save
>> area.
> 
> For once there's no clear error handling path for allocation failures
> on the (arbitarily sized) xsave state. On user code that can be barely
> tolerated, but for the kernel it would be deadly.
> 

Well, that's relatively easily dealt with... you'd have to allocate that 
state save area explicitly in kernel_fpu_begin(), and it would be up to 
the callers of that function to handle the resulting sleep and/or 
allocation failure -- we could even make kernel_fpu_begin() take a GFP_* 
flag.

Now, there are a few possibilities what to do with said state area.  One 
is to make it associated with the task; if used for something as RAID, 
this would mean pretty soon *all* (or nearly all) tasks have such a 
state area, and we might as well go back to allocating them preemptively 
on thread creation.  The other, of course, is to destroy it in 
kernel_fpu_end().  This may cause quite a bit of allocation/deallocation 
overhead, but perhaps this would be a decent use of a quicklist.

	-hpa



  parent reply	other threads:[~2008-06-29 22:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25 15:32 ABI change for device drivers using future AVX instruction set Agner Fog
2008-06-25 16:22 ` Arjan van de Ven
2008-06-25 19:54   ` Agner Fog
2008-06-25 20:09     ` Arjan van de Ven
2008-06-26  1:11   ` H. Peter Anvin
2008-06-27 11:31     ` Agner Fog
2008-06-27 14:22       ` Arjan van de Ven
2008-06-28  8:05         ` Agner Fog
2008-06-28  8:10           ` David Miller
2008-06-28 11:47           ` Andi Kleen
2008-06-28 15:09             ` Agner Fog
2008-06-28 15:44               ` Helge Hafting
2008-06-28 20:02               ` Andi Kleen
2008-06-29 11:33                 ` Avi Kivity
2008-06-29 12:21                   ` Andi Kleen
2008-06-29 12:31                     ` Avi Kivity
2008-06-29 13:07                       ` Andi Kleen
2008-06-29 13:18                         ` Avi Kivity
2008-06-29 13:23                           ` Andi Kleen
2008-06-29 13:29                             ` Avi Kivity
2008-06-29 22:08                             ` H. Peter Anvin [this message]
2008-06-29 12:29           ` Alan Cox
2008-07-01 15:30           ` Arjan van de Ven
2008-06-25 20:14 ` Alan Cox
2008-06-26 14:01 ` Andi Kleen

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=486807D6.9060407@zytor.com \
    --to=hpa@zytor.com \
    --cc=agner@agner.org \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=avi@qumranet.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox