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
next prev 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