On Mon, Jun 21, 2010 at 12:33 AM, Alexander Motin wrote:
> Brandon Gooch wrote:
>> On Sun, Jun 20, 2010 at 3:35 PM, Doug Barton wrote:
>>> On 06/20/10 08:47, Alexander Motin wrote:
While this can be done in sysctl.conf, it would be better to do it in
loader.conf to make it applied from
Brandon Gooch wrote:
> On Sun, Jun 20, 2010 at 3:35 PM, Doug Barton wrote:
>> On 06/20/10 08:47, Alexander Motin wrote:
>>> While this can be done in sysctl.conf, it would be better to do it in
>>> loader.conf to make it applied from the beginning, without on-the-fly
>>> timers change.
>> You're p
On Sun, Jun 20, 2010 at 3:35 PM, Doug Barton wrote:
> On 06/20/10 08:47, Alexander Motin wrote:
>>
>> While this can be done in sysctl.conf, it would be better to do it in
>> loader.conf to make it applied from the beginning, without on-the-fly
>> timers change.
>
> You're probably right that for
On 06/20/10 08:47, Alexander Motin wrote:
While this can be done in sysctl.conf, it would be better to do it in
loader.conf to make it applied from the beginning, without on-the-fly
timers change.
You're probably right that for something this fundamental it's better to
do it in loader.conf, ho
Brandon Gooch wrote:
> On Sun, Jun 20, 2010 at 1:17 AM, Alexander Motin wrote:
> In by /boot/loader.conf, I now have:
>
> # Power Saving
> kern.hz="100"
> #hint.apic.0.clock="0"
> #hint.atrtc.0.clock="0"
> hint.p4tcc.0.disabled="1"
> hint.p4tcc.1.disabled="1"
> hint.acpi_throttle.0.disabled="1"
>
On Sun, Jun 20, 2010 at 1:17 AM, Alexander Motin wrote:
> Brandon Gooch wrote:
>> I've been testing these patches since the first iteration
>> (et.20100606), and I haven't discovered any related issues.
>
> Thank you!
>
>> I am unclear about the number of interrupts I should expect from the
>> hpe
Brandon Gooch wrote:
> I've been testing these patches since the first iteration
> (et.20100606), and I haven't discovered any related issues.
Thank you!
> I am unclear about the number of interrupts I should expect from the
> hpet0 device (compared to the 99 from the rtc at 100Hz), so here is
>
In message: <4c0e5646.1060...@freebsd.org>
Alexander Motin writes:
: Brandon Gooch wrote:
: > Alexander, do you feel that the code is at a stage where meaningful
: > user testing can occur?
:
: I think yes. I've touched a lot of legacy code, so it would be nice to
: know what I may ha
Brandon Gooch wrote:
> I'm giving http://people.freebsd.org/~mav/et.20100607.patch a go right now...
>
> After patching and recompiling the kernel, I'm up and running.
>
> What information/feedback would you like to see from us users?
As always: what is working and especially what is not. What t
On Tue, Jun 8, 2010 at 9:40 AM, Alexander Motin wrote:
> Brandon Gooch wrote:
>> Alexander, do you feel that the code is at a stage where meaningful
>> user testing can occur?
>
> I think yes. I've touched a lot of legacy code, so it would be nice to
> know what I may have broken. For example, i82
Brandon Gooch wrote:
> Alexander, do you feel that the code is at a stage where meaningful
> user testing can occur?
I think yes. I've touched a lot of legacy code, so it would be nice to
know what I may have broken. For example, i8254 and RTC drivers now more
dependent on attaching to PnP/ACPI re
On Tue, Jun 8, 2010 at 12:24 AM, Tsuyoshi Ozawa wrote:
> 2010/6/6, Alexander Motin :
>> Hi.
>>
>> Most of x86 systems now has at least 4 types of event timers: i8254,
>> RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily
>> hardcoded and absolutely not scalable. I have reimple
2010/6/6, Alexander Motin :
> Hi.
>
> Most of x86 systems now has at least 4 types of event timers: i8254,
> RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily
> hardcoded and absolutely not scalable. I have reimplemented it, trying
> to solve these issues.
>
> I did such thing
Hi Alexander,
* Alexander Motin wrote:
> Ed Schouten wrote:
> > Just out of curiosity, how does this work relate to things like having a
> > tickless kernel?
>
> It is almost mandatory prerequisite. We can't do any fancy timer stuff
> without unified timer API. Tsuyoshi Ozawa in his Dynamic Tick
Ed Schouten wrote:
> * Alexander Motin wrote:
>> Most of x86 systems now has at least 4 types of event timers: i8254,
>> RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily
>> hardcoded and absolutely not scalable. I have reimplemented it, trying
>> to solve these issues.
>
>
Hi Alexander,
* Alexander Motin wrote:
> Most of x86 systems now has at least 4 types of event timers: i8254,
> RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily
> hardcoded and absolutely not scalable. I have reimplemented it, trying
> to solve these issues.
Just out of cu
Hi.
Most of x86 systems now has at least 4 types of event timers: i8254,
RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily
hardcoded and absolutely not scalable. I have reimplemented it, trying
to solve these issues.
I did such things:
- created unified timer driver's API (
17 matches
Mail list logo
