Re: high-res-timers start code.
Gabriel Paubert wrote: > > On Mon, 23 Apr 2001, george anzinger wrote: > > > "Robert H. de Vries" wrote: > > > > > > On Monday 23 April 2001 19:45, you wrote: > > > > > > > By the way, is the user land stuff the same for all "arch"s? > > > > > > Not if you plan to handle the CPU cycle counter in user space. That is at > > > least what I would propose. > > > > Just got interesting, lets let the world look in. > > > > What did you have in mind here? I suspect that on some archs the cycle > > counter is not available to user code. I know that on parisc it is > > optionally available (kernel can set a bit to make it available), but by > > it self it is only good for intervals. You need to peg some value to a > > CLOCK to use it to get timeofday, for instance. > > On Intel there is a also bit to disable unprivileged RDTSC, IIRC. On PPC > the timebase is always available (but the old 601 needs spacial casing: it > uses different registers and does not count in binary :-(). > > > On the other hand, if there is an area of memory that both users and > > system can read but only system can write, one might put the soft clock > > there. This would allow gettimeofday (with the cycle counter) to work > > without a system call. To the best of my knowledge the system does not > > have such an area as yet. > > > > comments? > > Well, there may be work in this area, since x86-64 will not enter kernel > mode for gettimeofday() if I understand correctly what Andrea said. Linus > hinted once at exporting (kernel) code to user space. > > Some data also will also need to be accessible but as long as you don't > guarantee compatibility on data layout, only AFAIU on interface for these > calls (it was not clear to me if it would be a fixed address forever or > dynamic linking with kernel exported symbols), it's not a problem. HPUX passes some kernel addresses to programs on the initial start up, i.e. the primary entry point where exec starts the task. In this case the addresses are in registers. I think HPUX also passes addresses back to the kernel at this time, but those are done with a system call. In any case, such a change requires a user land relink, something that may want the kernel to move from 2.x.x to 3.x.x (depending on version conventions :). I think the real problem has more to do with the "minor" variations on various archs, for example the 601 ppc above and the i386 TSC is only available in the "newer" machines. This would require user land configuration based on fine points of the arch, stuff "only the kernel knows for sure". So what do we do in the meantime? Comments? George > > Of course it will SIGSEGV instead of returning -EFAULT but this is a good > thing IMHO, nobody checks for -EFAULT from gettimeofday(). I think > that system calls should rather force SIGSEGV than return -EFAULT anyway, > to make syscalls indistinguishable from pure library calls. > > Regards, > Gabriel. - 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-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: high-res-timers start code.
On Mon, 23 Apr 2001, george anzinger wrote: > "Robert H. de Vries" wrote: > > > > On Monday 23 April 2001 19:45, you wrote: > > > > > By the way, is the user land stuff the same for all "arch"s? > > > > Not if you plan to handle the CPU cycle counter in user space. That is at > > least what I would propose. > > Just got interesting, lets let the world look in. > > What did you have in mind here? I suspect that on some archs the cycle > counter is not available to user code. I know that on parisc it is > optionally available (kernel can set a bit to make it available), but by > it self it is only good for intervals. You need to peg some value to a > CLOCK to use it to get timeofday, for instance. On Intel there is a also bit to disable unprivileged RDTSC, IIRC. On PPC the timebase is always available (but the old 601 needs spacial casing: it uses different registers and does not count in binary :-(). > On the other hand, if there is an area of memory that both users and > system can read but only system can write, one might put the soft clock > there. This would allow gettimeofday (with the cycle counter) to work > without a system call. To the best of my knowledge the system does not > have such an area as yet. > > comments? Well, there may be work in this area, since x86-64 will not enter kernel mode for gettimeofday() if I understand correctly what Andrea said. Linus hinted once at exporting (kernel) code to user space. Some data also will also need to be accessible but as long as you don't guarantee compatibility on data layout, only AFAIU on interface for these calls (it was not clear to me if it would be a fixed address forever or dynamic linking with kernel exported symbols), it's not a problem. Of course it will SIGSEGV instead of returning -EFAULT but this is a good thing IMHO, nobody checks for -EFAULT from gettimeofday(). I think that system calls should rather force SIGSEGV than return -EFAULT anyway, to make syscalls indistinguishable from pure library calls. Regards, Gabriel. - 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-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: high-res-timers start code.
On Mon, 23 Apr 2001, george anzinger wrote: Robert H. de Vries wrote: On Monday 23 April 2001 19:45, you wrote: By the way, is the user land stuff the same for all archs? Not if you plan to handle the CPU cycle counter in user space. That is at least what I would propose. Just got interesting, lets let the world look in. What did you have in mind here? I suspect that on some archs the cycle counter is not available to user code. I know that on parisc it is optionally available (kernel can set a bit to make it available), but by it self it is only good for intervals. You need to peg some value to a CLOCK to use it to get timeofday, for instance. On Intel there is a also bit to disable unprivileged RDTSC, IIRC. On PPC the timebase is always available (but the old 601 needs spacial casing: it uses different registers and does not count in binary :-(). On the other hand, if there is an area of memory that both users and system can read but only system can write, one might put the soft clock there. This would allow gettimeofday (with the cycle counter) to work without a system call. To the best of my knowledge the system does not have such an area as yet. comments? Well, there may be work in this area, since x86-64 will not enter kernel mode for gettimeofday() if I understand correctly what Andrea said. Linus hinted once at exporting (kernel) code to user space. Some data also will also need to be accessible but as long as you don't guarantee compatibility on data layout, only AFAIU on interface for these calls (it was not clear to me if it would be a fixed address forever or dynamic linking with kernel exported symbols), it's not a problem. Of course it will SIGSEGV instead of returning -EFAULT but this is a good thing IMHO, nobody checks for -EFAULT from gettimeofday(). I think that system calls should rather force SIGSEGV than return -EFAULT anyway, to make syscalls indistinguishable from pure library calls. Regards, Gabriel. - 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-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: high-res-timers start code.
Gabriel Paubert wrote: On Mon, 23 Apr 2001, george anzinger wrote: Robert H. de Vries wrote: On Monday 23 April 2001 19:45, you wrote: By the way, is the user land stuff the same for all archs? Not if you plan to handle the CPU cycle counter in user space. That is at least what I would propose. Just got interesting, lets let the world look in. What did you have in mind here? I suspect that on some archs the cycle counter is not available to user code. I know that on parisc it is optionally available (kernel can set a bit to make it available), but by it self it is only good for intervals. You need to peg some value to a CLOCK to use it to get timeofday, for instance. On Intel there is a also bit to disable unprivileged RDTSC, IIRC. On PPC the timebase is always available (but the old 601 needs spacial casing: it uses different registers and does not count in binary :-(). On the other hand, if there is an area of memory that both users and system can read but only system can write, one might put the soft clock there. This would allow gettimeofday (with the cycle counter) to work without a system call. To the best of my knowledge the system does not have such an area as yet. comments? Well, there may be work in this area, since x86-64 will not enter kernel mode for gettimeofday() if I understand correctly what Andrea said. Linus hinted once at exporting (kernel) code to user space. Some data also will also need to be accessible but as long as you don't guarantee compatibility on data layout, only AFAIU on interface for these calls (it was not clear to me if it would be a fixed address forever or dynamic linking with kernel exported symbols), it's not a problem. HPUX passes some kernel addresses to programs on the initial start up, i.e. the primary entry point where exec starts the task. In this case the addresses are in registers. I think HPUX also passes addresses back to the kernel at this time, but those are done with a system call. In any case, such a change requires a user land relink, something that may want the kernel to move from 2.x.x to 3.x.x (depending on version conventions :). I think the real problem has more to do with the minor variations on various archs, for example the 601 ppc above and the i386 TSC is only available in the newer machines. This would require user land configuration based on fine points of the arch, stuff only the kernel knows for sure. So what do we do in the meantime? Comments? George Of course it will SIGSEGV instead of returning -EFAULT but this is a good thing IMHO, nobody checks for -EFAULT from gettimeofday(). I think that system calls should rather force SIGSEGV than return -EFAULT anyway, to make syscalls indistinguishable from pure library calls. Regards, Gabriel. - 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-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: high-res-timers start code.
On Monday 23 April 2001 22:43, George Anzinger wrote: > "Robert H. de Vries" wrote: > > On Monday 23 April 2001 19:45, you wrote: > > > By the way, is the user land stuff the same for all "arch"s? > > > > Not if you plan to handle the CPU cycle counter in user space. That is at > > least what I would propose. > > Just got interesting, lets let the world look in. > > What did you have in mind here? I suspect that on some archs the cycle > counter is not available to user code. I know that on parisc it is > optionally available (kernel can set a bit to make it available), but by > it self it is only good for intervals. You need to peg some value to a > CLOCK to use it to get timeofday, for instance. > > On the other hand, if there is an area of memory that both users and > system can read but only system can write, one might put the soft clock > there. This would allow gettimeofday (with the cycle counter) to work > without a system call. To the best of my knowledge the system does not > have such an area as yet. It obviously is an architecture dependent thing. I know of two archtictures which have such a counter: your standard pentium and up and the SGI systems from at least the Indy and up. I wouldn't be surprised if most CPU's have such a counter. If you look at some of the architecture specific code for the gettimeofday code you would quickly find out which architectures have such a feature. I have some code for the intel in my user space library. For the SGI I also have some code, but only for IRIX. I guess for Linux we could do similar code. Robert -- Robert de Vries [EMAIL PROTECTED] - 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-info.html Please read the FAQ at http://www.tux.org/lkml/
high-res-timers start code.
"Robert H. de Vries" wrote: > > On Monday 23 April 2001 19:45, you wrote: > > > By the way, is the user land stuff the same for all "arch"s? > > Not if you plan to handle the CPU cycle counter in user space. That is at > least what I would propose. Just got interesting, lets let the world look in. What did you have in mind here? I suspect that on some archs the cycle counter is not available to user code. I know that on parisc it is optionally available (kernel can set a bit to make it available), but by it self it is only good for intervals. You need to peg some value to a CLOCK to use it to get timeofday, for instance. On the other hand, if there is an area of memory that both users and system can read but only system can write, one might put the soft clock there. This would allow gettimeofday (with the cycle counter) to work without a system call. To the best of my knowledge the system does not have such an area as yet. comments? George > System call stuff, yes. There may be gotcha's in the area of 32/64 > interfaces. Almost all 64 bit archs also support 32 bit interfaces (check out > the stuff in my patch regarding the SPARC, kindly donated by Jakub Jelinek). > > Robert > > -- > Robert de Vries > [EMAIL PROTECTED] - 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-info.html Please read the FAQ at http://www.tux.org/lkml/
high-res-timers start code.
Robert H. de Vries wrote: On Monday 23 April 2001 19:45, you wrote: By the way, is the user land stuff the same for all archs? Not if you plan to handle the CPU cycle counter in user space. That is at least what I would propose. Just got interesting, lets let the world look in. What did you have in mind here? I suspect that on some archs the cycle counter is not available to user code. I know that on parisc it is optionally available (kernel can set a bit to make it available), but by it self it is only good for intervals. You need to peg some value to a CLOCK to use it to get timeofday, for instance. On the other hand, if there is an area of memory that both users and system can read but only system can write, one might put the soft clock there. This would allow gettimeofday (with the cycle counter) to work without a system call. To the best of my knowledge the system does not have such an area as yet. comments? George System call stuff, yes. There may be gotcha's in the area of 32/64 interfaces. Almost all 64 bit archs also support 32 bit interfaces (check out the stuff in my patch regarding the SPARC, kindly donated by Jakub Jelinek). Robert -- Robert de Vries [EMAIL PROTECTED] - 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-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: high-res-timers start code.
On Monday 23 April 2001 22:43, George Anzinger wrote: Robert H. de Vries wrote: On Monday 23 April 2001 19:45, you wrote: By the way, is the user land stuff the same for all archs? Not if you plan to handle the CPU cycle counter in user space. That is at least what I would propose. Just got interesting, lets let the world look in. What did you have in mind here? I suspect that on some archs the cycle counter is not available to user code. I know that on parisc it is optionally available (kernel can set a bit to make it available), but by it self it is only good for intervals. You need to peg some value to a CLOCK to use it to get timeofday, for instance. On the other hand, if there is an area of memory that both users and system can read but only system can write, one might put the soft clock there. This would allow gettimeofday (with the cycle counter) to work without a system call. To the best of my knowledge the system does not have such an area as yet. It obviously is an architecture dependent thing. I know of two archtictures which have such a counter: your standard pentium and up and the SGI systems from at least the Indy and up. I wouldn't be surprised if most CPU's have such a counter. If you look at some of the architecture specific code for the gettimeofday code you would quickly find out which architectures have such a feature. I have some code for the intel in my user space library. For the SGI I also have some code, but only for IRIX. I guess for Linux we could do similar code. Robert -- Robert de Vries [EMAIL PROTECTED] - 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-info.html Please read the FAQ at http://www.tux.org/lkml/
