Hi!
> On 03 May 2001 09:13:00 +0200,
> [EMAIL PROTECTED] (Kai Henningsen) wrote:
> >[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in
><[EMAIL PROTECTED]>:
> >
> >> PS: Hmm, how do you do timewarp for just one userland appliation with
> >> this installed?
> >
> >1. What on earth for?
>
>
Hi!
> > > PS: Hmm, how do you do timewarp for just one userland appliation with
> > > this installed?
> >
> > 1. What on earth for?
>
> Y2K testing was one previous example.
>
> > 2. How do you do it today, and why wouldn't that work?
>
> LD_PRELOAD and providing its still using a lib call
Hi!
> > That means that for fooling closed-source statically-linked binary,
> > you now need to patch kernel. That's regression; subterfugue.org could
> > do this with normal user rights in 2.4.0.
>
> This is particularly pretty, but something that might work:
>
> 1. a "deceiver" process
Hi!
That means that for fooling closed-source statically-linked binary,
you now need to patch kernel. That's regression; subterfugue.org could
do this with normal user rights in 2.4.0.
This is particularly pretty, but something that might work:
1. a deceiver process creates a shared
Hi!
PS: Hmm, how do you do timewarp for just one userland appliation with
this installed?
1. What on earth for?
Y2K testing was one previous example.
2. How do you do it today, and why wouldn't that work?
LD_PRELOAD and providing its still using a lib call it would. I dont
Hi!
On 03 May 2001 09:13:00 +0200,
[EMAIL PROTECTED] (Kai Henningsen) wrote:
[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in
[EMAIL PROTECTED]:
PS: Hmm, how do you do timewarp for just one userland appliation with
this installed?
1. What on earth for?
Y10K testing :)
um, presumably this new magic page won't eliminate the old syscall entry
points. so just use those for UML.
-dean
On Fri, 4 May 2001, Pavel Machek wrote:
> Hi!
>
> > > > That means that for fooling closed-source statically-linked binary,
> > >
> > > If they are using glibc then you have the
On Thu, May 03, 2001 at 09:19:15PM +0100, Alan Cox wrote:
> If they are using glibc then you have the right to the object to link
> with the library and the library source under the LGPL. I dont know of any
> app using its own C lib
qmail is nearly there.
--
http://www.PowerDNS.com
Hi!
> > > That means that for fooling closed-source statically-linked binary,
> >
> > If they are using glibc then you have the right to the object to link
> > with the library and the library source under the LGPL. I dont know of any
> > app using its own C lib
>
> Some don't use any libc at
Hi!
That means that for fooling closed-source statically-linked binary,
If they are using glibc then you have the right to the object to link
with the library and the library source under the LGPL. I dont know of any
app using its own C lib
Some don't use any libc at all, some
On Thu, May 03, 2001 at 09:19:15PM +0100, Alan Cox wrote:
If they are using glibc then you have the right to the object to link
with the library and the library source under the LGPL. I dont know of any
app using its own C lib
qmail is nearly there.
--
http://www.PowerDNS.com
um, presumably this new magic page won't eliminate the old syscall entry
points. so just use those for UML.
-dean
On Fri, 4 May 2001, Pavel Machek wrote:
Hi!
That means that for fooling closed-source statically-linked binary,
If they are using glibc then you have the right to the
On Thu, May 03, 2001 at 09:19:15PM +0100, Alan Cox wrote:
> > That means that for fooling closed-source statically-linked binary,
>
> If they are using glibc then you have the right to the object to link
> with the library and the library source under the LGPL. I dont know of any
> app using its
> That means that for fooling closed-source statically-linked binary,
If they are using glibc then you have the right to the object to link
with the library and the library source under the LGPL. I dont know of any
app using its own C lib
>
-
To unsubscribe from this list: send the line
On Thu, 3 May 2001, Pavel Machek wrote:
> That means that for fooling closed-source statically-linked binary,
> you now need to patch kernel. That's regression; subterfugue.org could
> do this with normal user rights in 2.4.0.
This is particularly pretty, but something that might work:
1. a
Hi!
> > > > Whatever happened to that hack that was discussed a year or two ago?
> > > > The one where (also on IA32) a magic page was set up by the kernel
> > > > containing code for fast system calls, and the kernel would write
> > > > calibation information to that magic page. The code
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote:
> On 03 May 2001 09:13:00 +0200,
> [EMAIL PROTECTED] (Kai Henningsen) wrote:
> >[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in
><[EMAIL PROTECTED]>:
> >
> >> PS: Hmm, how do you do timewarp for just one userland appliation
Pavel Machek wrote:
> > >
> > > Whatever happened to that hack that was discussed a year or two ago?
> > > The one where (also on IA32) a magic page was set up by the kernel
> > > containing code for fast system calls, and the kernel would write
> > > calibation information to that magic page.
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote:
> >2. How do you do it today, and why wouldn't that work?
>
> LD_PRELOAD on a library that overrides gettimeofday(). I can see no
> reason why that would not continue to work.
Static linkage?
> What would stop working
> are
> > PS: Hmm, how do you do timewarp for just one userland appliation with
> > this installed?
>
> 1. What on earth for?
Y2K testing was one previous example.
> 2. How do you do it today, and why wouldn't that work?
LD_PRELOAD and providing its still using a lib call it would. I dont see the
On 03 May 2001 09:13:00 +0200,
[EMAIL PROTECTED] (Kai Henningsen) wrote:
>[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in <[EMAIL PROTECTED]>:
>
>> PS: Hmm, how do you do timewarp for just one userland appliation with
>> this installed?
>
>1. What on earth for?
Y10K testing :)
>2. How
[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in <[EMAIL PROTECTED]>:
> PS: Hmm, how do you do timewarp for just one userland appliation with
> this installed?
1. What on earth for?
2. How do you do it today, and why wouldn't that work?
MfG Kai
-
To unsubscribe from this list: send the
[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in [EMAIL PROTECTED]:
PS: Hmm, how do you do timewarp for just one userland appliation with
this installed?
1. What on earth for?
2. How do you do it today, and why wouldn't that work?
MfG Kai
-
To unsubscribe from this list: send the
On 03 May 2001 09:13:00 +0200,
[EMAIL PROTECTED] (Kai Henningsen) wrote:
[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in [EMAIL PROTECTED]:
PS: Hmm, how do you do timewarp for just one userland appliation with
this installed?
1. What on earth for?
Y10K testing :)
2. How do you do it
PS: Hmm, how do you do timewarp for just one userland appliation with
this installed?
1. What on earth for?
Y2K testing was one previous example.
2. How do you do it today, and why wouldn't that work?
LD_PRELOAD and providing its still using a lib call it would. I dont see the
original
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote:
2. How do you do it today, and why wouldn't that work?
LD_PRELOAD on a library that overrides gettimeofday(). I can see no
reason why that would not continue to work.
Static linkage?
What would stop working
are timewarp
Pavel Machek wrote:
Whatever happened to that hack that was discussed a year or two ago?
The one where (also on IA32) a magic page was set up by the kernel
containing code for fast system calls, and the kernel would write
calibation information to that magic page. The code written
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote:
On 03 May 2001 09:13:00 +0200,
[EMAIL PROTECTED] (Kai Henningsen) wrote:
[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in
[EMAIL PROTECTED]:
PS: Hmm, how do you do timewarp for just one userland appliation with
this
Hi!
Whatever happened to that hack that was discussed a year or two ago?
The one where (also on IA32) a magic page was set up by the kernel
containing code for fast system calls, and the kernel would write
calibation information to that magic page. The code written there
On Thu, 3 May 2001, Pavel Machek wrote:
That means that for fooling closed-source statically-linked binary,
you now need to patch kernel. That's regression; subterfugue.org could
do this with normal user rights in 2.4.0.
This is particularly pretty, but something that might work:
1. a
That means that for fooling closed-source statically-linked binary,
If they are using glibc then you have the right to the object to link
with the library and the library source under the LGPL. I dont know of any
app using its own C lib
-
To unsubscribe from this list: send the line
On Thu, May 03, 2001 at 09:19:15PM +0100, Alan Cox wrote:
That means that for fooling closed-source statically-linked binary,
If they are using glibc then you have the right to the object to link
with the library and the library source under the LGPL. I dont know of any
app using its own C
>From my experience system calls are not an issue.
What costs a lot is moving data around, since modern CPUs spend most of their
time in memory/bus wait cycles...
- Fabio
Linus Torvalds wrote:
> >I think that applies to all really high-performance servers.
>
> Note that it is definitely not
In article <[EMAIL PROTECTED]>,
Matti Aarnio <[EMAIL PROTECTED]> wrote:
>On Sun, Apr 29, 2001 at 02:16:43PM -0700, Jim Gettys wrote:
>...
>> "X is an exercise in avoiding system calls". I think I said this around
>> 1984-1985.
>> - Jim
>
>I think that applies to
On Sun, Apr 29, 2001 at 02:16:43PM -0700, Jim Gettys wrote:
...
> "X is an exercise in avoiding system calls". I think I said this around
> 1984-1985.
> - Jim
I think that applies to all really high-performance servers.
Definitely it applies to ZMailer, which
On Wed, 2 May 2001, Andi Kleen wrote:
> > Whatever happened to that hack that was discussed a year or two ago?
> > The one where (also on IA32) a magic page was set up by the kernel
> > containing code for fast system calls, and the kernel would write
> > calibation information to that magic
[sorry for the late answer -- i was involuntarily offline for a few days]
On Sat, Apr 28, 2001 at 04:56:27PM -0600, Richard Gooch wrote:
> Whatever happened to that hack that was discussed a year or two ago?
> The one where (also on IA32) a magic page was set up by the kernel
> containing code
[sorry for the late answer -- i was involuntarily offline for a few days]
On Sat, Apr 28, 2001 at 04:56:27PM -0600, Richard Gooch wrote:
Whatever happened to that hack that was discussed a year or two ago?
The one where (also on IA32) a magic page was set up by the kernel
containing code for
On Wed, 2 May 2001, Andi Kleen wrote:
Whatever happened to that hack that was discussed a year or two ago?
The one where (also on IA32) a magic page was set up by the kernel
containing code for fast system calls, and the kernel would write
calibation information to that magic page. The
On Sun, Apr 29, 2001 at 02:16:43PM -0700, Jim Gettys wrote:
...
X is an exercise in avoiding system calls. I think I said this around
1984-1985.
- Jim
I think that applies to all really high-performance servers.
Definitely it applies to ZMailer, which before
In article [EMAIL PROTECTED],
Matti Aarnio [EMAIL PROTECTED] wrote:
On Sun, Apr 29, 2001 at 02:16:43PM -0700, Jim Gettys wrote:
...
X is an exercise in avoiding system calls. I think I said this around
1984-1985.
- Jim
I think that applies to all really
From my experience system calls are not an issue.
What costs a lot is moving data around, since modern CPUs spend most of their
time in memory/bus wait cycles...
- Fabio
Linus Torvalds wrote:
I think that applies to all really high-performance servers.
Note that it is definitely not
Hi!
> > > In x86-64 there are special vsyscalls btw to solve this problem that export
> > > a lockless kernel gettimeofday()
> >
> > Whatever happened to that hack that was discussed a year or two ago?
> > The one where (also on IA32) a magic page was set up by the kernel
> > containing code
Hi!
In x86-64 there are special vsyscalls btw to solve this problem that export
a lockless kernel gettimeofday()
Whatever happened to that hack that was discussed a year or two ago?
The one where (also on IA32) a magic page was set up by the kernel
containing code for fast system
> The point is: The code in that "magic page" that considers the
> tradeoff is KERNEL code, which is designed to care about such
> trade-offs for that machine. Glibc never knows this stuff and
> shouldn't, because it is already bloated.
glibc is bloated because it cares about such stuff and
At 12:29 AM -0700 2001-04-30, H. Peter Anvin wrote:
>"David S. Miller" wrote:
>>
>> dean gaudet writes:
>> > i was kind of solving a different problem with the code page
>>though -- the
>> > ability to use rdtsc on SMP boxes with processors of varying speeds and
>> > synchronizations.
>>
H. Peter Anvin writes:
> RDTSC in Crusoe processors does basically this.
Hmmm, one of the advantages of using a seperate tick register for this
constant clock is that you can still do cycle accurate asm code
analysis even when the cpu is down clocked.
The joys of compatability I suppose :-)
"David S. Miller" wrote:
>
> dean gaudet writes:
> > i was kind of solving a different problem with the code page though -- the
> > ability to use rdtsc on SMP boxes with processors of varying speeds and
> > synchronizations.
>
> A better way to solve that problem is the way UltraSPARC-III
dean gaudet writes:
> i was kind of solving a different problem with the code page though -- the
> ability to use rdtsc on SMP boxes with processors of varying speeds and
> synchronizations.
A better way to solve that problem is the way UltraSPARC-III do and
future ia64 systems will, by way
dean gaudet writes:
i was kind of solving a different problem with the code page though -- the
ability to use rdtsc on SMP boxes with processors of varying speeds and
synchronizations.
A better way to solve that problem is the way UltraSPARC-III do and
future ia64 systems will, by way of
David S. Miller wrote:
dean gaudet writes:
i was kind of solving a different problem with the code page though -- the
ability to use rdtsc on SMP boxes with processors of varying speeds and
synchronizations.
A better way to solve that problem is the way UltraSPARC-III do and
H. Peter Anvin writes:
RDTSC in Crusoe processors does basically this.
Hmmm, one of the advantages of using a seperate tick register for this
constant clock is that you can still do cycle accurate asm code
analysis even when the cpu is down clocked.
The joys of compatability I suppose :-)
At 12:29 AM -0700 2001-04-30, H. Peter Anvin wrote:
David S. Miller wrote:
dean gaudet writes:
i was kind of solving a different problem with the code page
though -- the
ability to use rdtsc on SMP boxes with processors of varying speeds and
synchronizations.
A better way to
The point is: The code in that magic page that considers the
tradeoff is KERNEL code, which is designed to care about such
trade-offs for that machine. Glibc never knows this stuff and
shouldn't, because it is already bloated.
glibc is bloated because it cares about such stuff and complex
On Sun, Apr 29, 2001 at 04:18:27PM -0400, Gregory Maxwell wrote:
> having both the code and a comprehensive jump-table might become tough in a
In the x86-64 implementation there's no jump table. The original design
had a jump table but Peter raised the issue that indirect jumps are very
costly
On Sun, Apr 29, 2001 at 09:38:04PM +0200, Jamie Lokier wrote:
> Fwiw, modern x86 has global TLB entries too.
my x86-64 implementation is marking the tlb entry global of course (so
it's not flushed during context switch):
#define __PAGE_KERNEL_VSYSCALL \
(_PAGE_PRESENT | _PAGE_USER |
H. Peter Anvin writes:
> The thing that made me say we discussed this last month was
> Richard's comment that it had already been implemented (which it
> has, by Andrea, for x86-64.) The idea of doing it for i386 has been
> kicked around for
Correction: I didn't say it had been implemented. I
Gregory Maxwell writes:
> On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote:
> [snip]
> > The point is: The code in that "magic page" that considers the
> > tradeoff is KERNEL code, which is designed to care about such
> > trade-offs for that machine. Glibc never knows this stuff and
> >
Ingo Oeser writes:
> On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> > Ingo Oeser writes:
> > > There we have 10x faster memmove/memcpy/bzero for 1K blocks
> > > granularity (== alignment is 1K and size is multiple of 1K), that
> > > is done by the memory controller.
> > This
>
> Short summary: depending on how much you were talking general idea versus
> specifics, you can go arbitrarily far back (I wouldn't be surprised if
> shared memory techniques were used regularly before memory protection.)
>
> Fair?
Very fair.
>
> Not to pick on you or anyone else, but it
Jim Gettys wrote:
>
> The "put the time into a magic location in shared memory" goes back...
>
Short summary: depending on how much you were talking general idea versus
specifics, you can go arbitrarily far back (I wouldn't be surprised if
shared memory techniques were used regularly before
The "put the time into a magic location in shared memory" goes back, as
far as I know, to Bob Scheifler or myself for the X Window System, sometime
around 1984 or 1985: we put it into a page of shared memory where we used
a circular buffer scheme to put input events (keyboard/mice), so that
we
In article <[EMAIL PROTECTED]> you wrote:
> Yes, but we currently have more than 10K cycles for doing
> memset of a page.
make that 3800 or so. (700 Mhz AMD Duron)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Followup to: <[EMAIL PROTECTED]>
By author:dean gaudet <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Sun, 29 Apr 2001, Jeff Garzik wrote:
>
> > "H. Peter Anvin" wrote:
> > > We discussed this at the Summit, not a year or two ago. x86-64 has
> > > it, and it wouldn't be too bad
On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote:
[snip]
> The point is: The code in that "magic page" that considers the
> tradeoff is KERNEL code, which is designed to care about such
> trade-offs for that machine. Glibc never knows this stuff and
> shouldn't, because it is already
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> Ingo Oeser writes:
> > There we have 10x faster memmove/memcpy/bzero for 1K blocks
> > granularity (== alignment is 1K and size is multiple of 1K), that
> > is done by the memory controller.
> This sounds different to me. Using the
Gregory Maxwell writes:
> Would it make sence to have libc use the magic page for all
> syscalls? Then on cpus with a fast syscall instruction, the magic
> page could contain the needed junk in userspace to use it.
That's pretty much what Linus suggested. He proposed having a new
syscall
On Sun, Apr 29, 2001 at 01:02:13PM -0600, Richard Gooch wrote:
> Gregory Maxwell writes:
> > On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> > > Ingo Oeser writes:
> > > > On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> > > > > The idea is that the one thing
David S. Miller wrote:
> It's particularly attractive on sparc64 because you
> can use a "global" TLB entry which is thus shared between all address
> spaces.
Fwiw, modern x86 has global TLB entries too.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Gregory Maxwell writes:
> On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> > Ingo Oeser writes:
> > > On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> > > > The idea is that the one thing one tends to optimize for new cpus
> > > > is the memcpy/memset
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> Ingo Oeser writes:
> > On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> > > The idea is that the one thing one tends to optimize for new cpus
> > > is the memcpy/memset implementation. What better way to shield
>
Ingo Oeser writes:
> On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> > The idea is that the one thing one tends to optimize for new cpus
> > is the memcpy/memset implementation. What better way to shield
> > libc from having to be updated for new cpus but to put it into
> >
On Sun, 29 Apr 2001, Jeff Garzik wrote:
> "H. Peter Anvin" wrote:
> > We discussed this at the Summit, not a year or two ago. x86-64 has
> > it, and it wouldn't be too bad to do in i386... just noone did.
>
> It came up long before that. I refer to the technique in a post dated
> Nov 17, even
On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> The idea is that the one thing one tends to optimize for new cpus
> is the memcpy/memset implementation. What better way to shield
> libc from having to be updated for new cpus but to put it into
> the kernel in this magic page?
Jeff Garzik writes:
> After a couple of suggestions for improving things, Linus chimed in
> with the magic page suggestion.
Since this is being brought up again, I want to mention something.
If we are going to map in a page like this, there are other cool
things one could do with this page.
"H. Peter Anvin" wrote:
>
> Followup to: <[EMAIL PROTECTED]>
> By author:Richard Gooch <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> > >
> > > In x86-64 there are special vsyscalls btw to solve this problem that export
> > > a lockless kernel gettimeofday()
> >
> > Whatever
H. Peter Anvin wrote:
Followup to: [EMAIL PROTECTED]
By author:Richard Gooch [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
In x86-64 there are special vsyscalls btw to solve this problem that export
a lockless kernel gettimeofday()
Whatever happened to that hack that was
Jeff Garzik writes:
After a couple of suggestions for improving things, Linus chimed in
with the magic page suggestion.
Since this is being brought up again, I want to mention something.
If we are going to map in a page like this, there are other cool
things one could do with this page.
On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
The idea is that the one thing one tends to optimize for new cpus
is the memcpy/memset implementation. What better way to shield
libc from having to be updated for new cpus but to put it into
the kernel in this magic page?
On Sun, 29 Apr 2001, Jeff Garzik wrote:
H. Peter Anvin wrote:
We discussed this at the Summit, not a year or two ago. x86-64 has
it, and it wouldn't be too bad to do in i386... just noone did.
It came up long before that. I refer to the technique in a post dated
Nov 17, even though I
Ingo Oeser writes:
On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
The idea is that the one thing one tends to optimize for new cpus
is the memcpy/memset implementation. What better way to shield
libc from having to be updated for new cpus but to put it into
the kernel
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
Ingo Oeser writes:
On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
The idea is that the one thing one tends to optimize for new cpus
is the memcpy/memset implementation. What better way to shield
libc
Gregory Maxwell writes:
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
Ingo Oeser writes:
On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
The idea is that the one thing one tends to optimize for new cpus
is the memcpy/memset implementation. What
David S. Miller wrote:
It's particularly attractive on sparc64 because you
can use a global TLB entry which is thus shared between all address
spaces.
Fwiw, modern x86 has global TLB entries too.
-- Jamie
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
On Sun, Apr 29, 2001 at 01:02:13PM -0600, Richard Gooch wrote:
Gregory Maxwell writes:
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
Ingo Oeser writes:
On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
The idea is that the one thing one tends to
Gregory Maxwell writes:
Would it make sence to have libc use the magic page for all
syscalls? Then on cpus with a fast syscall instruction, the magic
page could contain the needed junk in userspace to use it.
That's pretty much what Linus suggested. He proposed having a new
syscall interface
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
Ingo Oeser writes:
There we have 10x faster memmove/memcpy/bzero for 1K blocks
granularity (== alignment is 1K and size is multiple of 1K), that
is done by the memory controller.
This sounds different to me. Using the memory
Followup to: [EMAIL PROTECTED]
By author:dean gaudet [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
On Sun, 29 Apr 2001, Jeff Garzik wrote:
H. Peter Anvin wrote:
We discussed this at the Summit, not a year or two ago. x86-64 has
it, and it wouldn't be too bad to do in i386...
On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote:
[snip]
The point is: The code in that magic page that considers the
tradeoff is KERNEL code, which is designed to care about such
trade-offs for that machine. Glibc never knows this stuff and
shouldn't, because it is already bloated.
In article [EMAIL PROTECTED] you wrote:
Yes, but we currently have more than 10K cycles for doing
memset of a page.
make that 3800 or so. (700 Mhz AMD Duron)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
The put the time into a magic location in shared memory goes back, as
far as I know, to Bob Scheifler or myself for the X Window System, sometime
around 1984 or 1985: we put it into a page of shared memory where we used
a circular buffer scheme to put input events (keyboard/mice), so that
we
Jim Gettys wrote:
The put the time into a magic location in shared memory goes back...
Short summary: depending on how much you were talking general idea versus
specifics, you can go arbitrarily far back (I wouldn't be surprised if
shared memory techniques were used regularly before memory
Short summary: depending on how much you were talking general idea versus
specifics, you can go arbitrarily far back (I wouldn't be surprised if
shared memory techniques were used regularly before memory protection.)
Fair?
Very fair.
Not to pick on you or anyone else, but it is
Ingo Oeser writes:
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
Ingo Oeser writes:
There we have 10x faster memmove/memcpy/bzero for 1K blocks
granularity (== alignment is 1K and size is multiple of 1K), that
is done by the memory controller.
This sounds different
Gregory Maxwell writes:
On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote:
[snip]
The point is: The code in that magic page that considers the
tradeoff is KERNEL code, which is designed to care about such
trade-offs for that machine. Glibc never knows this stuff and
shouldn't,
H. Peter Anvin writes:
The thing that made me say we discussed this last month was
Richard's comment that it had already been implemented (which it
has, by Andrea, for x86-64.) The idea of doing it for i386 has been
kicked around for
Correction: I didn't say it had been implemented. I just
On Sun, Apr 29, 2001 at 09:38:04PM +0200, Jamie Lokier wrote:
Fwiw, modern x86 has global TLB entries too.
my x86-64 implementation is marking the tlb entry global of course (so
it's not flushed during context switch):
#define __PAGE_KERNEL_VSYSCALL \
(_PAGE_PRESENT | _PAGE_USER |
On Sun, Apr 29, 2001 at 04:18:27PM -0400, Gregory Maxwell wrote:
having both the code and a comprehensive jump-table might become tough in a
In the x86-64 implementation there's no jump table. The original design
had a jump table but Peter raised the issue that indirect jumps are very
costly
Followup to: <[EMAIL PROTECTED]>
By author:Richard Gooch <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> >
> > In x86-64 there are special vsyscalls btw to solve this problem that export
> > a lockless kernel gettimeofday()
>
> Whatever happened to that hack that was discussed a year
Andi Kleen writes:
> On Sat, Apr 28, 2001 at 05:52:42PM +0200, Ingo Molnar wrote:
> >
> > On Sat, 28 Apr 2001, Andi Kleen wrote:
> >
> > > You can also just use the cycle counter directly in most modern CPUs.
> > > It can be read with a single instruction. In fact modern glibc will do
> > > it
1 - 100 of 106 matches
Mail list logo
