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
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 pretends to try to handle changing cpufreq levels, but does tha
19 matches
Mail list logo
