On Thu, 18 Jan 2007, Andi Kleen wrote:
> > let me know what you think... thanks.
>
> It's ok, although I would like to have the file in a separate directory.
cool -- do you have a directory in mind?
and would you like this change as two separate patches or one combined
patch?
thanks
-dean
-
T
> let me know what you think... thanks.
It's ok, although I would like to have the file in a separate directory.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-i
On Sat, 13 Jan 2007, dean gaudet wrote:
> ok here is the latest rev of this patch (against 2.6.20-rc4).
>
> timings in cycles:
>
> baseline patchedbaseline patched
> no cache no cachecache cache
> k8 pre-revF2116 14
ok here is the latest rev of this patch (against 2.6.20-rc4).
timings in cycles:
baseline patchedbaseline patched
no cache no cachecache cache
k8 pre-revF2116 1417
k8 revF3117 14
> 64-bit processes can't actually use their
> LDT can they?
The kernel supports LDT for 64bit processes, it just is not commonly
used.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://v
On Sat, 6 Jan 2007, dean gaudet wrote:
> below is a patch which improves vgetcpu latency on all x86_64
> implementations i've tested.
>
> Nathan Laredo pointed out the sgdt/sidt/sldt instructions are
> userland-accessible and we could use their limit fields to tuck away a few
> bits of per-cpu
below is a patch which improves vgetcpu latency on all x86_64
implementations i've tested.
Nathan Laredo pointed out the sgdt/sidt/sldt instructions are
userland-accessible and we could use their limit fields to tuck away a few
bits of per-cpu information.
vgetcpu generally uses lsl at present
7 matches
Mail list logo