* H. Peter Anvin wrote:
> On 12/26/2013 10:09 PM, H. Peter Anvin wrote:
> > On 12/26/2013 11:00 AM, Linus Torvalds wrote:
> >>
> >> Interestingly, looking at the cp_new_stat() profiles, the games we
> >> play to get efficient range checking seem to actually hurt us. Maybe
> >> it's the "sbb" tha
On 12/26/2013 10:09 PM, H. Peter Anvin wrote:
> On 12/26/2013 11:00 AM, Linus Torvalds wrote:
>>
>> Interestingly, looking at the cp_new_stat() profiles, the games we
>> play to get efficient range checking seem to actually hurt us. Maybe
>> it's the "sbb" that is just expensive, or maybe it's turn
On 12/26/2013 11:00 AM, Linus Torvalds wrote:
>
> Interestingly, looking at the cp_new_stat() profiles, the games we
> play to get efficient range checking seem to actually hurt us. Maybe
> it's the "sbb" that is just expensive, or maybe it's turning a (very
> predictable) conditional branch into
Ok the sign bit doesn't really make any sense on second thought... to work with
set_fs() we have to load something from memory anyway and then we might as well
do a compare...
"H. Peter Anvin" wrote:
>On 12/26/2013 11:00 AM, Linus Torvalds wrote:
>>
>> Interestingly, looking at the cp_new_stat
On 12/26/2013 11:00 AM, Linus Torvalds wrote:
>
> Interestingly, looking at the cp_new_stat() profiles, the games we
> play to get efficient range checking seem to actually hurt us. Maybe
> it's the "sbb" that is just expensive, or maybe it's turning a (very
> predictable) conditional branch into
On Tue, Dec 24, 2013 at 12:46 PM, Ingo Molnar wrote:
>
> Looks cool - it looks rather similar to the try/catch model Richard
> Henderson came up with many eons ago when we implemented the original
> exception mechanism for Linux, which IIRC we decided wasn't safe due
> to lack of compiler support.
* Linus Torvalds wrote:
> Here's both x86 people and filesystem people involved, because this
> hacky RFC patch touches both.
>
> NOTE NOTE NOTE! I've modified "cp_new_stat()" in place, in a way that
> is x86-64 specific. So the attached patch *only* works on x86-64, and
> will very actively br
Right, the __label__ declaration should take care of it.
Linus Torvalds wrote:
>On Mon, Dec 23, 2013 at 4:00 PM, H. Peter Anvin wrote:
>>
>> I guess I'm a bit puzzled... the current code should be just fine if
>> everything is present, and do we really care about the performance if
>we
>> actual
On Mon, Dec 23, 2013 at 4:00 PM, H. Peter Anvin wrote:
>
> I guess I'm a bit puzzled... the current code should be just fine if
> everything is present, and do we really care about the performance if we
> actually have an error condition?
I think we should. You could make it to do something like
On 12/21/2013 12:27 PM, Linus Torvalds wrote:
>
> HOWEVER. On x86, doing an efficient field-at-a-time copy also requires
> us to use put_user_try() and put_user_catch() in order to not have
> tons of clac/stac instructions for the extended permission testing.
> And the implementation of that was a
On Sat, Dec 21, 2013 at 2:54 PM, John Stoffel wrote:
>
> Any numbers of how much better this is? I'm travelling
> tomorrow, so I won't have time to spin up a VM and play, though it's
> tempting to do so.
On most _real_ loads, the kernel footprint is pretty small, and
obviously if you do IO or ot
Linus> Here's both x86 people and filesystem people involved, because this
Linus> hacky RFC patch touches both.
Linus> NOTE NOTE NOTE! I've modified "cp_new_stat()" in place, in a way that
Linus> is x86-64 specific. So the attached patch *only* works on x86-64, and
Linus> will very actively break
Here's both x86 people and filesystem people involved, because this
hacky RFC patch touches both.
NOTE NOTE NOTE! I've modified "cp_new_stat()" in place, in a way that
is x86-64 specific. So the attached patch *only* works on x86-64, and
will very actively break on anything else. That's intentiona
13 matches
Mail list logo
