On Monday 06 December 2010 02:38 pm, Andriy Gapon wrote:
> on 06/12/2010 21:27 Jung-uk Kim said the following:
> > On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote:
> >> on 06/12/2010 21:01 Jung-uk Kim said the following:
> >>> :-) Don't get me wrong, I generally agree with you *iff* it
> >>
on 06/12/2010 21:27 Jung-uk Kim said the following:
> On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote:
>> on 06/12/2010 21:01 Jung-uk Kim said the following:
>>> :-) Don't get me wrong, I generally agree with you *iff* it does
>>> : not
>>>
>>> hurt too much. Anyway, this issue should be r
On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote:
> on 06/12/2010 21:01 Jung-uk Kim said the following:
> > :-) Don't get me wrong, I generally agree with you *iff* it does
> > : not
> >
> > hurt too much. Anyway, this issue should be resolved from the
> > root, i.e., kern_resouce.c, if pos
On Monday 06 December 2010 01:56 pm, Andriy Gapon wrote:
> on 06/12/2010 20:34 Jung-uk Kim said the following:
> > I understand that. However, it is not clear to me why you want
> > to pessimize performance of old hardware. If you can convince me
> > old hardware with slow timecounter hardware (e
on 06/12/2010 21:01 Jung-uk Kim said the following:
> :-) Don't get me wrong, I generally agree with you *iff* it does not
> hurt too much. Anyway, this issue should be resolved from the root,
> i.e., kern_resouce.c, if possible.
But what to resolve there?
I just want to always have a stable so
On Monday 06 December 2010 01:40 pm, Andriy Gapon wrote:
> on 06/12/2010 20:34 Jung-uk Kim said the following:
> > On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote:
> >> on 06/12/2010 19:42 Jung-uk Kim said the following:
> >>> Sigh... Please see the history of calcru() in
> >>> sys/kern/ke
on 06/12/2010 20:34 Jung-uk Kim said the following:
> I understand that. However, it is not clear to me why you want to
> pessimize performance of old hardware. If you can convince me old
> hardware with slow timecounter hardware (e.g., i8254) does not hurt
> too much, maybe it's okay.
Overlo
on 06/12/2010 20:34 Jung-uk Kim said the following:
> On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote:
>> on 06/12/2010 19:42 Jung-uk Kim said the following:
>>> Sigh... Please see the history of calcru() in
>>> sys/kern/kern_resource.c. Most important ones are:
>>>
>>> http://svn.freebsd
On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote:
> on 06/12/2010 19:42 Jung-uk Kim said the following:
> > Sigh... Please see the history of calcru() in
> > sys/kern/kern_resource.c. Most important ones are:
> >
> > http://svn.freebsd.org/viewvc/base?view=revision&revision=155444
> > http
on 06/12/2010 19:42 Jung-uk Kim said the following:
> Sigh... Please see the history of calcru() in
> sys/kern/kern_resource.c. Most important ones are:
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=155444
> http://svn.freebsd.org/viewvc/base?view=revision&revision=155534
>
> B
On Saturday 04 December 2010 06:12 am, Andriy Gapon wrote:
> on 04/12/2010 02:38 Jung-uk Kim said the following:
> > If my understanding is correct, your patch uses the dummy
> > timecounter until a real timecounter is chosen.
>
> Perhaps this is one way to look at it.
> But I look at it differentl
on 04/12/2010 02:38 Jung-uk Kim said the following:
> If my understanding is correct, your patch uses the dummy timecounter
> until a real timecounter is chosen.
Perhaps this is one way to look at it.
But I look at it differently - the patch makes cpu_ticks refer to tc_cpu_ticks.
That is, it make
Jung-uk Kim wrote:
On Friday 03 December 2010 01:14 pm, Andriy Gapon wrote:
on 03/12/2010 20:05 Jung-uk Kim said the following:
On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote:
FreeBSD uses cpu_ticks [function pointer] in a few places for a
few things like process CPU ti
On Friday 03 December 2010 06:47 pm, Andriy Gapon wrote:
> on 03/12/2010 22:03 Jung-uk Kim said the following:
> > On Friday 03 December 2010 01:14 pm, Andriy Gapon wrote:
> >> on 03/12/2010 20:05 Jung-uk Kim said the following:
> >>> On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote:
>
on 03/12/2010 22:03 Jung-uk Kim said the following:
> On Friday 03 December 2010 01:14 pm, Andriy Gapon wrote:
>> on 03/12/2010 20:05 Jung-uk Kim said the following:
>>> On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote:
FreeBSD uses cpu_ticks [function pointer] in a few places for a
>>>
On Friday 03 December 2010 01:14 pm, Andriy Gapon wrote:
> on 03/12/2010 20:05 Jung-uk Kim said the following:
> > On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote:
> >> FreeBSD uses cpu_ticks [function pointer] in a few places for a
> >> few things like process CPU time accounting. On x86
on 03/12/2010 20:05 Jung-uk Kim said the following:
> On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote:
>> FreeBSD uses cpu_ticks [function pointer] in a few places for a few
>> things like process CPU time accounting. On x86 cpu_ticks always
>> points to rdtsc. If TSC is not invariant that
On Friday 03 December 2010 12:26 pm, Andriy Gapon wrote:
> FreeBSD uses cpu_ticks [function pointer] in a few places for a few
> things like process CPU time accounting. On x86 cpu_ticks always
> points to rdtsc. If TSC is not invariant that leads to incorrect
> accounting of "CPU ticks". The code
18 matches
Mail list logo