On Thu, Sep 20, 2012 at 7:31 AM, Steven Rostedt wrote:
> On Mon, 2012-09-17 at 16:49 -0700, Andy Lutomirski wrote:
>
>> I haven't looked in any great detail, but the approach looks sensible
>> and should slow down the vsyscall code.
>>
>> That being said, as long as you're playing with this, here
On Mon, 2012-09-17 at 16:49 -0700, Andy Lutomirski wrote:
> I haven't looked in any great detail, but the approach looks sensible
> and should slow down the vsyscall code.
>
> That being said, as long as you're playing with this, here are a
> couple thoughts:
>
> 1. The TSC-reading code does
On Wed, Sep 19, 2012 at 02:11:02PM -0700, John Stultz wrote:
> Now, I suspect the difficult part will be finding someone with the
> time and interest to try get the vdso gettime working on ia64 (or
> s390 or powerpc), and then try to unify the kernel side
> implementation. Reducing the maintenance
On Wed, Sep 19, 2012 at 02:11:02PM -0700, John Stultz wrote:
Now, I suspect the difficult part will be finding someone with the
time and interest to try get the vdso gettime working on ia64 (or
s390 or powerpc), and then try to unify the kernel side
implementation. Reducing the maintenance
On Mon, 2012-09-17 at 16:49 -0700, Andy Lutomirski wrote:
I haven't looked in any great detail, but the approach looks sensible
and should slow down the vsyscall code.
That being said, as long as you're playing with this, here are a
couple thoughts:
1. The TSC-reading code does this:
On Thu, Sep 20, 2012 at 7:31 AM, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2012-09-17 at 16:49 -0700, Andy Lutomirski wrote:
I haven't looked in any great detail, but the approach looks sensible
and should slow down the vsyscall code.
That being said, as long as you're playing with
On Wed, Sep 19, 2012 at 1:50 PM, Luck, Tony wrote:
>> Does anything except the vDSO actually use the vDSO data page? It's
>> mapped as part of the vDSO image (i.e. at a non-constant address), and
>> it's not immediate obvious how userspace would locate that page.
>
> Just for reference - on ia64
On 09/19/2012 01:50 PM, Luck, Tony wrote:
Does anything except the vDSO actually use the vDSO data page? It's
mapped as part of the vDSO image (i.e. at a non-constant address), and
it's not immediate obvious how userspace would locate that page.
Just for reference - on ia64 the address of the
> Does anything except the vDSO actually use the vDSO data page? It's
> mapped as part of the vDSO image (i.e. at a non-constant address), and
> it's not immediate obvious how userspace would locate that page.
Just for reference - on ia64 the address of the entry point for the magic
fast system
On Wed, Sep 19, 2012 at 10:54 AM, John Stultz wrote:
> On 09/19/2012 10:03 AM, Richard Cochran wrote:
>>
>> On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote:
>>>
>>> With powerpc, there is no arch specific kernel code involved, its
>>> just a data structure the kernel exports that is
On 09/19/2012 10:03 AM, Richard Cochran wrote:
On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote:
With powerpc, there is no arch specific kernel code involved, its
just a data structure the kernel exports that is accessible to
userland. The execution logic lives in userland libraries,
On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote:
> On powerpc, I mean magic addresses where userland can find
> structures that it can use to calculate time.
...
> With powerpc, there is no arch specific kernel code involved, its
> just a data structure the kernel exports that is
On 09/18/2012 09:50 PM, Richard Cochran wrote:
On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
I believe its mostly historical, but on some architectures that
history has become an established ABI, making it technical.
Fine, but what do you mean by "ABI?" Are you talking about
On 09/18/2012 09:50 PM, Richard Cochran wrote:
On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
I believe its mostly historical, but on some architectures that
history has become an established ABI, making it technical.
Fine, but what do you mean by ABI? Are you talking about magic
On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote:
On powerpc, I mean magic addresses where userland can find
structures that it can use to calculate time.
...
With powerpc, there is no arch specific kernel code involved, its
just a data structure the kernel exports that is
On 09/19/2012 10:03 AM, Richard Cochran wrote:
On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote:
With powerpc, there is no arch specific kernel code involved, its
just a data structure the kernel exports that is accessible to
userland. The execution logic lives in userland libraries,
On Wed, Sep 19, 2012 at 10:54 AM, John Stultz john.stu...@linaro.org wrote:
On 09/19/2012 10:03 AM, Richard Cochran wrote:
On Wed, Sep 19, 2012 at 09:31:35AM -0700, John Stultz wrote:
With powerpc, there is no arch specific kernel code involved, its
just a data structure the kernel exports
Does anything except the vDSO actually use the vDSO data page? It's
mapped as part of the vDSO image (i.e. at a non-constant address), and
it's not immediate obvious how userspace would locate that page.
Just for reference - on ia64 the address of the entry point for the magic
fast system
On 09/19/2012 01:50 PM, Luck, Tony wrote:
Does anything except the vDSO actually use the vDSO data page? It's
mapped as part of the vDSO image (i.e. at a non-constant address), and
it's not immediate obvious how userspace would locate that page.
Just for reference - on ia64 the address of the
On Wed, Sep 19, 2012 at 1:50 PM, Luck, Tony tony.l...@intel.com wrote:
Does anything except the vDSO actually use the vDSO data page? It's
mapped as part of the vDSO image (i.e. at a non-constant address), and
it's not immediate obvious how userspace would locate that page.
Just for
On Tue, Sep 18, 2012 at 9:50 PM, Richard Cochran
wrote:
> On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
>> I believe its mostly historical, but on some architectures that
>> history has become an established ABI, making it technical.
>
> Fine, but what do you mean by "ABI?" Are you
On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
> I believe its mostly historical, but on some architectures that
> history has become an established ABI, making it technical.
Fine, but what do you mean by "ABI?" Are you talking about magic
addresses for functions?
Without knowing
On 09/18/2012 11:02 AM, Richard Cochran wrote:
On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote:
On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
2. There's nothing vsyscall-specific about the code in
vclock_gettime.c. In fact, the VVAR macro should work just fine in
kernel code. If
On Tue, Sep 18, 2012 at 11:02 AM, Richard Cochran
wrote:
> On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote:
>> On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
>> >2. There's nothing vsyscall-specific about the code in
>> >vclock_gettime.c. In fact, the VVAR macro should work just fine
On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote:
> On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
> >2. There's nothing vsyscall-specific about the code in
> >vclock_gettime.c. In fact, the VVAR macro should work just fine in
> >kernel code. If you moved all this code into a header,
On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote:
On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
2. There's nothing vsyscall-specific about the code in
vclock_gettime.c. In fact, the VVAR macro should work just fine in
kernel code. If you moved all this code into a header, then
On Tue, Sep 18, 2012 at 11:02 AM, Richard Cochran
richardcoch...@gmail.com wrote:
On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote:
On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
2. There's nothing vsyscall-specific about the code in
vclock_gettime.c. In fact, the VVAR macro should
On 09/18/2012 11:02 AM, Richard Cochran wrote:
On Mon, Sep 17, 2012 at 05:20:41PM -0700, John Stultz wrote:
On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
2. There's nothing vsyscall-specific about the code in
vclock_gettime.c. In fact, the VVAR macro should work just fine in
kernel code. If
On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
I believe its mostly historical, but on some architectures that
history has become an established ABI, making it technical.
Fine, but what do you mean by ABI? Are you talking about magic
addresses for functions?
Without knowing the
On Tue, Sep 18, 2012 at 9:50 PM, Richard Cochran
richardcoch...@gmail.com wrote:
On Tue, Sep 18, 2012 at 11:29:50AM -0700, John Stultz wrote:
I believe its mostly historical, but on some architectures that
history has become an established ABI, making it technical.
Fine, but what do you mean
On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
On Mon, Sep 17, 2012 at 3:04 PM, John Stultz wrote:
This item has been on my todo list for a number of years.
One interesting bit of the timekeeping code is that we internally
keep sub-nanosecond precision. This allows for really fine
grained
On Mon, Sep 17, 2012 at 5:20 PM, John Stultz wrote:
> On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
>>
>> On Mon, Sep 17, 2012 at 3:04 PM, John Stultz
>> wrote:
>>>
>>> Anyway, I'd greatly appreciate any thoughts or feedback on this
>>> approach.
>>
>> I haven't looked in any great detail, but
On Mon, Sep 17, 2012 at 3:04 PM, John Stultz wrote:
> This item has been on my todo list for a number of years.
>
> One interesting bit of the timekeeping code is that we internally
> keep sub-nanosecond precision. This allows for really fine
> grained error accounting, which allows us to keep
This item has been on my todo list for a number of years.
One interesting bit of the timekeeping code is that we internally
keep sub-nanosecond precision. This allows for really fine
grained error accounting, which allows us to keep long term
accuracy, even if the clocksource can only make very
This item has been on my todo list for a number of years.
One interesting bit of the timekeeping code is that we internally
keep sub-nanosecond precision. This allows for really fine
grained error accounting, which allows us to keep long term
accuracy, even if the clocksource can only make very
On Mon, Sep 17, 2012 at 3:04 PM, John Stultz john.stu...@linaro.org wrote:
This item has been on my todo list for a number of years.
One interesting bit of the timekeeping code is that we internally
keep sub-nanosecond precision. This allows for really fine
grained error accounting, which
On Mon, Sep 17, 2012 at 5:20 PM, John Stultz john.stu...@linaro.org wrote:
On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
On Mon, Sep 17, 2012 at 3:04 PM, John Stultz john.stu...@linaro.org
wrote:
Anyway, I'd greatly appreciate any thoughts or feedback on this
approach.
I haven't looked
On 09/17/2012 04:49 PM, Andy Lutomirski wrote:
On Mon, Sep 17, 2012 at 3:04 PM, John Stultz john.stu...@linaro.org wrote:
This item has been on my todo list for a number of years.
One interesting bit of the timekeeping code is that we internally
keep sub-nanosecond precision. This allows for
38 matches
Mail list logo
